// For flags

CVE-2022-49419

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

Severity Score

7.8
*CVSS v3.1

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

Track*
*SSVC
Descriptions

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.

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.

*Credits: N/A
CVSS Scores
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High
Attack Vector
Local
Attack Complexity
Low
Authentication
None
Confidentiality
None
Integrity
Complete
Availability
Complete
* Common Vulnerability Scoring System
SSVC
  • Decision:Track*
Exploitation
None
Automatable
No
Tech. Impact
Total
* Organization's Worst-case Scenario
Timeline
  • 2025-02-26 CVE Reserved
  • 2025-02-26 CVE Published
  • 2025-02-27 CVE Updated
  • 2025-02-27 EPSS Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
  • CWE-416: Use After Free
CAPEC
Affected Vendors, Products, and Versions
Vendor Product Version Other Status
Vendor Product Version Other Status <-- --> Vendor Product Version Other Status
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.15.41 < 5.15.46
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.15.41 < 5.15.46"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.17.9 < 5.17.14
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.17.9 < 5.17.14"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.18 < 5.18.3
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.18 < 5.18.3"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.18 < 5.19
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.18 < 5.19"
en
Affected