Bug 2347942 (CVE-2022-49419) - CVE-2022-49419 kernel: video: fbdev: vesafb: Fix a use-after-free due early fb_info cleanup
Summary: CVE-2022-49419 kernel: video: fbdev: vesafb: Fix a use-after-free due early f...
Keywords:
Status: NEW
Alias: CVE-2022-49419
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-02-26 03:12 UTC by OSIDB Bzimport
Modified: 2025-05-14 17:24 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2025-02-26 03:12:10 UTC
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.

Comment 1 Avinash Hanwate 2025-02-26 19:59:46 UTC
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2025022654-CVE-2022-49419-fc59@gregkh/T


Note You need to log in before you can comment on or make changes to this bug.