https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 14:10:06 +0000 https://vulnerability.circl.lu/vuln/cve-2022-49419 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>video: fbdev: vesafb: Fix a use-after-free due early fb_info cleanup</p> <p>Commit b3c9a924aab6 (&#34;fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than .remove&#34;) 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.</p> <p>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.</p> <p>But that change didn&#39;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.</p> <p>If that&#39;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.</p> <p>To prevent that, move the expression containing the info-&gt;par to happen before the unregister_framebuffer() function call.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>video: fbdev: vesafb: Fix a use-after-free due early fb_info cleanup</p> <p>Commit b3c9a924aab6 (&#34;fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than .remove&#34;) 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.</p> <p>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.</p> <p>But that change didn&#39;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.</p> <p>If that&#39;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.</p> <p>To prevent that, move the expression containing the info-&gt;par to happen before the unregister_framebuffer() function call.</p> https://vulnerability.circl.lu/vuln/cve-2022-49419