Описание
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 unregiste...
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.
Ссылки
- https://nvd.nist.gov/vuln/detail/CVE-2022-49419
- https://git.kernel.org/stable/c/0fac5f8fb1bc2fc4f8714bf5e743c9cc3f547c63
- https://git.kernel.org/stable/c/acde4003efc16480375543638484d8f13f2e99a3
- https://git.kernel.org/stable/c/d260cad015945d1f4bb9b028a096f648506106a2
- https://git.kernel.org/stable/c/f605f5558ecc175ec70016a3c15f007cb6386531
Связанные уязвимости
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_fram...
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_fram...
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_f
In the Linux kernel, the following vulnerability has been resolved: v ...
Уязвимость функции vesafb_remove() модуля drivers/video/fbdev/vesafb.c - драйвера поддержки устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации