CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-36969 – drm/amd/display: Fix division by zero in setup_dsc_config
https://notcve.org/view.php?id=CVE-2024-36969
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix division by zero in setup_dsc_config When slice_height is 0, the division by slice_height in the calculation of the number of slices will cause a division by zero driver crash. This leaves the kernel in a state that requires a reboot. This patch adds a check to avoid the division by zero. The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor connected via Thunderbolt. The amdgpu driver crashed with this exception when I rebooted the system with the monitor connected. kernel: ? • https://git.kernel.org/stable/c/a32c8f951c8a456c1c251e1dcdf21787f8066445 https://git.kernel.org/stable/c/91402e0e5de9124a3108db7a14163fcf9a6d322f https://git.kernel.org/stable/c/7e4f50dfc98c49b3dc6875a35c3112522fb25639 https://git.kernel.org/stable/c/f187fcbbb8f8bf10c6687f0beae22509369f7563 https://git.kernel.org/stable/c/308de6be0c9c7ba36915c0d398e771725c0ea911 https://git.kernel.org/stable/c/130afc8a886183a94cf6eab7d24f300014ff87ba • CWE-369: Divide By Zero •
CVSS: 6.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-36968 – Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
https://notcve.org/view.php?id=CVE-2024-36968
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init() l2cap_le_flowctl_init() can cause both div-by-zero and an integer overflow since hdev->le_mtu may not fall in the valid range. Move MTU from hci_dev to hci_conn to validate MTU and stop the connection process earlier if MTU is invalid. Also, add a missing validation in read_buffer_size() and make it return an error value if the validation fails. Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a kzalloc failure and invalid MTU value. divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci0 hci_rx_work RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547 Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c 89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42 RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246 RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084 R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000 FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: L2CAP: corrige div-by-zero en l2cap_le_flowctl_init() l2cap_le_flowctl_init() puede causar tanto div-by-zero como un desbordamiento de enteros ya que hdev->le_mtu puede no caer el rango válido. Mueva MTU de hci_dev a hci_conn para validar MTU y detener el proceso de conexión antes si MTU no es válido. Además, agregue una validación faltante en read_buffer_size() y haga que devuelva un valor de error si la validación falla. Ahora hci_conn_add() devuelve ERR_PTR() ya que puede fallar debido a una falla de kzalloc y un valor de MTU no válido. error de división: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: GW 6.9.0-rc5+ #20 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0-1 01/04/2014 Cola de trabajo: hci0 hci_rx_work RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547 Código: e8 17 17 0c 00 66 41 89 9f 84 00 00 novio 01 00 00 00 41 b8 02 00 00 00 4c 89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42 RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246 RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 810bc0f7c0 RDI: ffffc90002dcb66f RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa R10: 0084000000ffaaaa R11: 0000000000000000 R12 : ffff88810d65a084 R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000 FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 50033 CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0 PKRU: 55555554 Seguimiento de llamadas: l2cap_le_connect_req net /bluetooth/l2cap_core.c:4902 [en línea] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [en línea] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [en línea] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c: 6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [en línea] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 Process_one_work kernel/workqueue.c: 3254 [en línea] Process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 trabajador_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/ Process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Módulos vinculados en: ---[ end trace 0000000000000000 ]--- • https://git.kernel.org/stable/c/6ed58ec520ad2b2fe3f955c8a5fd0eecafccebdf https://git.kernel.org/stable/c/ad3f7986c5a0f82b8b66a0afe1cc1f5421e1d674 https://git.kernel.org/stable/c/dfece2b4e3759759b2bdfac2cd6d0ee9fbf055f3 https://git.kernel.org/stable/c/d2b2f7d3936dc5990549bc36ab7ac7ac37f22c30 https://git.kernel.org/stable/c/4d3dbaa252257d20611c3647290e6171f1bbd6c8 https://git.kernel.org/stable/c/a5b862c6a221459d54e494e88965b48dcfa6cc44 • CWE-190: Integer Overflow or Wraparound CWE-369: Divide By Zero •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36964 – fs/9p: only translate RWX permissions for plain 9P2000
https://notcve.org/view.php?id=CVE-2024-36964
In the Linux kernel, the following vulnerability has been resolved: fs/9p: only translate RWX permissions for plain 9P2000 Garbage in plain 9P2000's perm bits is allowed through, which causes it to be able to set (among others) the suid bit. This was presumably not the intent since the unix extended bits are handled explicitly and conditionally on .u. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/9p: solo traduce permisos RWX para 9P2000 simple. Se permite el paso de basura en bits permanentes de 9P2000 simple, lo que hace que pueda establecer (entre otros) el bit suid. Probablemente esta no era la intención, ya que los bits extendidos de Unix se manejan explícita y condicionalmente en .u. • https://git.kernel.org/stable/c/e90bc596a74bb905e0a45bf346038c3f9d1e868d https://git.kernel.org/stable/c/df1962a199783ecd66734d563caf0fedecf08f96 https://git.kernel.org/stable/c/5a605930e19f451294bd838754f7d66c976a8a2c https://git.kernel.org/stable/c/ad4f65328661392de74e3608bb736fedf3b67e32 https://git.kernel.org/stable/c/ca9b5c81f0c918c63d73d962ed8a8e231f840bc8 https://git.kernel.org/stable/c/e55c601af3b1223a84f9f27f9cdbd2af5e203bf3 https://git.kernel.org/stable/c/157d468e34fdd3cb1ddc07c2be32fb3b02826b02 https://git.kernel.org/stable/c/cd25e15e57e68a6b18dc9323047fe9c68 •
CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36960 – drm/vmwgfx: Fix invalid reads in fence signaled events
https://notcve.org/view.php?id=CVE-2024-36960
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix invalid reads in fence signaled events Correctly set the length of the drm_event to the size of the structure that's actually used. The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/vmwgfx: corrige lecturas no válidas en eventos señalizados de valla establezca correctamente la longitud de drm_event al tamaño de la estructura que realmente se utiliza. La longitud de drm_event se configuró en la estructura principal en lugar de en drm_vmw_event_fence que se supone debe leerse. drm_read usa el parámetro de longitud para copiar el evento al espacio del usuario, lo que resulta en lecturas oob. This vulnerability allows local attackers to disclose sensitive information on affected installations of Linux Kernel. An attacker must first obtain the ability to execute high-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the handling of vmw fence events. • https://git.kernel.org/stable/c/8b7de6aa84682a3396544fd88cd457f95484573a https://git.kernel.org/stable/c/2f527e3efd37c7c5e85e8aa86308856b619fa59f https://git.kernel.org/stable/c/cef0962f2d3e5fd0660c8efb72321083a1b531a9 https://git.kernel.org/stable/c/3cd682357c6167f636aec8ac0efaa8ba61144d36 https://git.kernel.org/stable/c/b7bab33c4623c66e3398d5253870d4e88c52dfc0 https://git.kernel.org/stable/c/0dbfc73670b357456196130551e586345ca48e1b https://git.kernel.org/stable/c/7b5fd3af4a250dd0a2a558e07b43478748eb5d22 https://git.kernel.org/stable/c/deab66596dfad14f1c54eeefdb7242834 • CWE-125: Out-of-bounds Read •
CVSS: 4.4EPSS: 0%CPEs: 5EXPL: 0CVE-2024-36952 – scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
https://notcve.org/view.php?id=CVE-2024-36952
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Move NPIV's transport unregistration to after resource clean up There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric. Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch. Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: lpfc: Mover la anulación del registro de transporte de NPIV a después de la limpieza de recursos. Hay casos después de la eliminación de NPIV en los que el conmutador de tejido todavía cree que el NPIV está registrado en el tejido. • https://git.kernel.org/stable/c/f2c7f029051edc4b394bb48edbe2297575abefe0 https://git.kernel.org/stable/c/0936809d968ecf81e0726fbd02ff2a5732d960c3 https://git.kernel.org/stable/c/76337eb8daee32bcc67742efab3168ed4ca299d0 https://git.kernel.org/stable/c/718602cd15f4c5710850090ea3066a89eeb46278 https://git.kernel.org/stable/c/4ddf01f2f1504fa08b766e8cfeec558e9f8eef6c https://access.redhat.com/security/cve/CVE-2024-36952 https://bugzilla.redhat.com/show_bug.cgi?id=2284598 • CWE-459: Incomplete Cleanup •