CVE-2023-52762 – virtio-blk: fix implicit overflow on virtio_max_dma_size
https://notcve.org/view.php?id=CVE-2023-52762
In the Linux kernel, the following vulnerability has been resolved: virtio-blk: fix implicit overflow on virtio_max_dma_size The following codes have an implicit conversion from size_t to u32: (u32)max_size = (size_t)virtio_max_dma_size(vdev); This may lead overflow, Ex (size_t)4G -> (u32)0. Once virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX instead. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: virtio-blk: corrige el desbordamiento implícito en virtio_max_dma_size. Los siguientes códigos tienen una conversión implícita de size_t a u32: (u32)max_size = (size_t)virtio_max_dma_size(vdev); Esto puede provocar un desbordamiento, Ex (size_t)4G -> (u32)0. Una vez que virtio_max_dma_size() tenga un tamaño mayor que U32_MAX, use U32_MAX en su lugar. • https://git.kernel.org/stable/c/72775cad7f572bb2501f9ea609e1d20e68f0b38b https://git.kernel.org/stable/c/472bd4787406bef2e8b41ee4c74d960a06a49a48 https://git.kernel.org/stable/c/017278f141141367f7d14b203e930b45b6ffffb9 https://git.kernel.org/stable/c/d667fe301dcbcb12d1d6494fc4b8abee2cb75d90 https://git.kernel.org/stable/c/fafb51a67fb883eb2dde352539df939a251851be https://access.redhat.com/security/cve/CVE-2023-52762 https://bugzilla.redhat.com/show_bug.cgi?id=2282623 • CWE-121: Stack-based Buffer Overflow •
CVE-2023-52760 – gfs2: Fix slab-use-after-free in gfs2_qd_dealloc
https://notcve.org/view.php?id=CVE-2023-52760
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix slab-use-after-free in gfs2_qd_dealloc In gfs2_put_super(), whether withdrawn or not, the quota should be cleaned up by gfs2_quota_cleanup(). Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu callback) has run for all gfs2_quota_data objects, resulting in use-after-free. Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling gfs2_make_fs_ro(), there is no need to call them again. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gfs2: corrige slab-use-after-free en gfs2_qd_dealloc. En gfs2_put_super(), ya sea retirada o no, gfs2_quota_cleanup() debe limpiar la cuota. De lo contrario, la estructura gfs2_sbd se liberará antes de que se ejecute gfs2_qd_dealloc (devolución de llamada de rcu) para todos los objetos gfs2_quota_data, lo que dará como resultado un use after free. Además, gfs2_destroy_threads() y gfs2_quota_cleanup() ya son llamados por gfs2_make_fs_ro(), por lo que en gfs2_put_super(), después de llamar a gfs2_make_fs_ro(), no es necesario volver a llamarlos. • https://git.kernel.org/stable/c/7ad4e0a4f61c57c3ca291ee010a9d677d0199fba https://git.kernel.org/stable/c/08a28272faa750d4357ea2cb48d2baefd778ea81 https://git.kernel.org/stable/c/bdcb8aa434c6d36b5c215d02a9ef07551be25a37 • CWE-416: Use After Free •
CVE-2023-52757 – smb: client: fix potential deadlock when releasing mids
https://notcve.org/view.php?id=CVE-2023-52757
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential deadlock when releasing mids All release_mid() callers seem to hold a reference of @mid so there is no need to call kref_put(&mid->refcount, __release_mid) under @server->mid_lock spinlock. If they don't, then an use-after-free bug would have occurred anyways. By getting rid of such spinlock also fixes a potential deadlock as shown below CPU 0 CPU 1 ------------------------------------------------------------------ cifs_demultiplex_thread() cifs_debug_data_proc_show() release_mid() spin_lock(&server->mid_lock); spin_lock(&cifs_tcp_ses_lock) spin_lock(&server->mid_lock) __release_mid() smb2_find_smb_tcon() spin_lock(&cifs_tcp_ses_lock) *deadlock* En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: client: corrige un posible punto muerto al liberar mids. Todos los llamadores de release_mid() parecen tener una referencia de @mid, por lo que no hay necesidad de llamar a kref_put(&mid->refcount, __release_mid ) en @servidor->mid_lock spinlock. Si no lo hacen, de todos modos se habría producido un error de use after free. Al deshacerse de dicho bloqueo de giro, también se soluciona un posible punto muerto como se muestra a continuación CPU 0 CPU 1 -------------------------------- ---------------------------------- cifs_demultiplex_thread() cifs_debug_data_proc_show() release_mid() spin_lock(&servidor->mid_lock) ; spin_lock(&cifs_tcp_ses_lock) spin_lock(&servidor->mid_lock) __release_mid() smb2_find_smb_tcon() spin_lock(&cifs_tcp_ses_lock) *punto muerto* • https://git.kernel.org/stable/c/9eb44db68c5b7f5aa22b8fc7de74a3e2e08d1f29 https://git.kernel.org/stable/c/b9bb9607b1fc12fca51f5632da25b36975f599bf https://git.kernel.org/stable/c/c1a5962f1462b64fe7b69f20a4b6af8067bc2d26 https://git.kernel.org/stable/c/e6322fd177c6885a21dd4609dc5e5c973d1a2eb7 https://access.redhat.com/security/cve/CVE-2023-52757 https://bugzilla.redhat.com/show_bug.cgi?id=2282641 • CWE-833: Deadlock •
CVE-2023-52754 – media: imon: fix access to invalid resource for the second interface
https://notcve.org/view.php?id=CVE-2023-52754
In the Linux kernel, the following vulnerability has been resolved: media: imon: fix access to invalid resource for the second interface imon driver probes two USB interfaces, and at the probe of the second interface, the driver assumes blindly that the first interface got bound with the same imon driver. It's usually true, but it's still possible that the first interface is bound with another driver via a malformed descriptor. Then it may lead to a memory corruption, as spotted by syzkaller; imon driver accesses the data from drvdata as struct imon_context object although it's a completely different one that was assigned by another driver. This patch adds a sanity check -- whether the first interface is really bound with the imon driver or not -- for avoiding the problem above at the probe time. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: imon: corrige el acceso a un recurso no válido para la segunda interfaz. El controlador imon prueba dos interfaces USB y, en la prueba de la segunda interfaz, el controlador asume ciegamente que la primera interfaz obtuvo atado con el mismo conductor imon. • https://git.kernel.org/stable/c/0f5068519f89d928d6c51100e4b274479123829f https://git.kernel.org/stable/c/5e0b788fb96be36d1baf1a5c88d09c7c82a0452a https://git.kernel.org/stable/c/b083aaf5db2eeca9e362723258e5d8698f7dd84e https://git.kernel.org/stable/c/10ec5a97f8f5a772a1a42b4eb27196b447cd3aa9 https://git.kernel.org/stable/c/2a493a34bd6e496c55fabedd82b957193ace178f https://git.kernel.org/stable/c/a1766a4fd83befa0b34d932d532e7ebb7fab1fa7 •
CVE-2023-52753 – drm/amd/display: Avoid NULL dereference of timing generator
https://notcve.org/view.php?id=CVE-2023-52753
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid NULL dereference of timing generator [Why & How] Check whether assigned timing generator is NULL or not before accessing its funcs to prevent NULL dereference. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: Evite la desreferencia NULL del generador de temporización [Por qué y cómo] Verifique si el generador de temporización asignado es NULL o no antes de acceder a sus funciones para evitar la desreferencia NULL. • https://git.kernel.org/stable/c/09909f515032fa80b921fd3118efe66b185d10fd https://git.kernel.org/stable/c/eac3e4760aa12159f7f5475d55a67b7933abc195 https://git.kernel.org/stable/c/79b6a90f4f2433312154cd68452b0ba501fa74db https://git.kernel.org/stable/c/4e497f1acd99075b13605b2e7fa0cba721a2cfd9 https://git.kernel.org/stable/c/8a06894666e0b462c9316b26ab615cefdd0d676c https://git.kernel.org/stable/c/6d8653b1a7a8dc938b566ae8c4f373b36e792c68 https://git.kernel.org/stable/c/df8bc953eed72371e43ca407bd063507f760cf89 https://git.kernel.org/stable/c/b1904ed480cee3f9f4036ea0e36d139cb • CWE-476: NULL Pointer Dereference •