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: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-36967 – KEYS: trusted: Fix memory leak in tpm2_key_encode()
https://notcve.org/view.php?id=CVE-2024-36967
In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix memory leak in tpm2_key_encode() 'scratch' is never freed. Fix this by calling kfree() in the success, and in the error case. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KEYS: confiable: corrige la pérdida de memoria en tpm2_key_encode() 'scratch' nunca se libera. Solucione este problema llamando a kfree() en caso de éxito y de error. • https://git.kernel.org/stable/c/f2219745250f388edacabe6cca73654131c67d0a https://git.kernel.org/stable/c/1e6914fa8e7798bcf3ce4a5b96ea4ac1d5571cdf https://git.kernel.org/stable/c/5d91238b590bd883c86ba7707c5c9096469c08b7 https://git.kernel.org/stable/c/e62835264d0352be6086975f18fdfed2b5520b13 https://git.kernel.org/stable/c/189c768932d435045b1fae12bf63e53866f06a28 https://git.kernel.org/stable/c/cf26a92f560eed5d6ddc3d441cc645950cbabc56 https://git.kernel.org/stable/c/ffcaa2172cc1a85ddb8b783de96d38ca8855e248 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-36965 – remoteproc: mediatek: Make sure IPI buffer fits in L2TCM
https://notcve.org/view.php?id=CVE-2024-36965
In the Linux kernel, the following vulnerability has been resolved: remoteproc: mediatek: Make sure IPI buffer fits in L2TCM The IPI buffer location is read from the firmware that we load to the System Companion Processor, and it's not granted that both the SRAM (L2TCM) size that is defined in the devicetree node is large enough for that, and while this is especially true for multi-core SCP, it's still useful to check on single-core variants as well. Failing to perform this check may make this driver perform R/W operations out of the L2TCM boundary, resulting (at best) in a kernel panic. To fix that, check that the IPI buffer fits, otherwise return a failure and refuse to boot the relevant SCP core (or the SCP at all, if this is single core). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: remoteproc: mediatek: asegúrese de que el búfer IPI encaje en L2TCM. La ubicación del búfer IPI se lee desde el firmware que cargamos en el procesador System Companion, y no se garantiza que tanto la SRAM ( L2TCM) que se define en el nodo del árbol de dispositivos es lo suficientemente grande para eso, y si bien esto es especialmente cierto para SCP de múltiples núcleos, también es útil verificar las variantes de un solo núcleo. No realizar esta verificación puede hacer que este controlador realice operaciones de lectura y escritura fuera del límite L2TCM, lo que resultará (en el mejor de los casos) en un pánico en el kernel. Para solucionarlo, verifique que el búfer IPI encaje; de lo contrario, devolverá una falla y se negará a iniciar el núcleo SCP relevante (o el SCP en absoluto, si es de un solo núcleo). • https://git.kernel.org/stable/c/3efa0ea743b77d1611501f7d8b4f320d032d73ae https://git.kernel.org/stable/c/00548ac6b14428719c970ef90adae2b3b48c0cdf https://git.kernel.org/stable/c/1d9e2de24533daca36cbf09e8d8596bf72b526b2 https://git.kernel.org/stable/c/26c6d7dc8c6a9fde9d362ab2eef6390efeff145e https://git.kernel.org/stable/c/838b49e211d59fa827ff9df062d4020917cffbdf https://git.kernel.org/stable/c/36c79eb4845551e9f6d28c663b38ce0ab03b84a9 https://git.kernel.org/stable/c/331f91d86f71d0bb89a44217cc0b2a22810bbd42 •
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 •