CVE-2022-49419 Affecting kernel-devel package, versions <5.14.21-150500.55.100.1


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.02% (4th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-SLES155-KERNELDEVEL-9699511
  • published15 Apr 2025
  • disclosed14 Apr 2025

Introduced: 14 Apr 2025

NewCVE-2022-49419  (opens in a new tab)

How to fix?

Upgrade SLES:15.5 kernel-devel to version 5.14.21-150500.55.100.1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-devel package and not the kernel-devel package as distributed by SLES. See How to fix? for SLES:15.5 relevant fixed versions and status.

In the Linux kernel, the following vulnerability has been resolved:

video: fbdev: vesafb: Fix a use-after-free due early fb_info cleanup

Commit b3c9a924aab6 ("fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than .remove") fixed a use-after-free error due the vesafb driver freeing the fb_info in the .remove handler instead of doing it in .fb_destroy.

This can happen if the .fb_destroy callback is executed after the .remove callback, since the former tries to access a pointer freed by the latter.

But that change didn't take into account that another possible scenario is that .fb_destroy is called before the .remove callback. For example, if no process has the fbdev chardev opened by the time the driver is removed.

If that's the case, fb_info will be freed when unregister_framebuffer() is called, making the fb_info pointer accessed in vesafb_remove() after that to no longer be valid.

To prevent that, move the expression containing the info->par to happen before the unregister_framebuffer() function call.

CVSS Base Scores

version 3.1