CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52638 – can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock
https://notcve.org/view.php?id=CVE-2023-52638
In the Linux kernel, the following vulnerability has been resolved: can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A reasonable fix is to change j1939_socks_lock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939_socks_lock is protecting, the code does not attempt to acquire any more locks. This would break the circular lock dependency, where, for example, the current thread already locks j1939_socks_lock and attempts to acquire sk_session_queue_lock, and at the same time, another thread attempts to acquire j1939_socks_lock while holding sk_session_queue_lock. NOTE: This patch along does not fix the unregister_netdevice bug reported by Syzbot; instead, it solves a deadlock situation to prepare for one or more further patches to actually fix the Syzbot bug, which appears to be a reference counting problem within the j1939 codebase. [mkl: remove unrelated newline change] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: j1939: previene el interbloqueo cambiando j1939_socks_lock a rwlock Los siguientes 3 bloqueos competirían entre sí, causando la situación de interbloqueo en el informe de error de Syzbot: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A Una solución razonable es cambiar j1939_socks_lock por un rwlock, ya que en las raras situaciones en las que se requiere un bloqueo de escritura para la lista vinculada que j1939_socks_lock está protegiendo, el código no intenta adquirir más bloqueos. Esto rompería la dependencia del bloqueo circular, donde, por ejemplo, el subproceso actual ya bloquea j1939_socks_lock e intenta adquirir sk_session_queue_lock y, al mismo tiempo, otro subproceso intenta adquirir j1939_socks_lock mientras mantiene sk_session_queue_lock. NOTA: Este parche no soluciona el error unregister_netdevice informado por Syzbot; en cambio, resuelve una situación de punto muerto para prepararse para uno o más parches adicionales para corregir el error Syzbot, que parece ser un problema de conteo de referencias dentro del código base j1939. [mkl: eliminar cambio de nueva línea no relacionado] A vulnerability was found in the Linux kernel's Controller Area Network (CAN) protocol, within the J1939 protocol implementation. • https://git.kernel.org/stable/c/03358aba991668d3bb2c65b3c82aa32c36851170 https://git.kernel.org/stable/c/aedda066d717a0b4335d7e0a00b2e3a61e40afcf https://git.kernel.org/stable/c/26dfe112ec2e95fe0099681f6aec33da13c2dd8e https://git.kernel.org/stable/c/559b6322f9480bff68cfa98d108991e945a4f284 https://git.kernel.org/stable/c/6cdedc18ba7b9dacc36466e27e3267d201948c8d https://access.redhat.com/security/cve/CVE-2023-52638 https://bugzilla.redhat.com/show_bug.cgi?id=2273082 • CWE-833: Deadlock •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52637 – can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)
https://notcve.org/view.php?id=CVE-2023-52637
In the Linux kernel, the following vulnerability has been resolved: can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER) Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...) modifies jsk->filters while receiving packets. Following trace was seen on affected system: ================================================================== BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] Read of size 4 at addr ffff888012144014 by task j1939/350 CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: print_report+0xd3/0x620 ? kasan_complete_mode_report_info+0x7d/0x200 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] kasan_report+0xc2/0x100 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] __asan_load4+0x84/0xb0 j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] j1939_sk_recv+0x20b/0x320 [can_j1939] ? __kasan_check_write+0x18/0x20 ? • https://git.kernel.org/stable/c/9d71dd0c70099914fcd063135da3c580865e924c https://git.kernel.org/stable/c/08de58abedf6e69396e1207e4f99ef8904b2b532 https://git.kernel.org/stable/c/978e50ef8c38dc71bd14d1b0143d554ff5d188ba https://git.kernel.org/stable/c/41ccb5bcbf03f02d820bc6ea8390811859f558f8 https://git.kernel.org/stable/c/4dd684d4bb3cd5454e0bf6e2a1bdfbd5c9c872ed https://git.kernel.org/stable/c/f84e7534457dcd7835be743517c35378bb4e7c50 https://git.kernel.org/stable/c/fc74b9cb789cae061bbca7b203a3842e059f6b5d https://git.kernel.org/stable/c/efe7cf828039aedb297c1f9920b638fff •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26684 – net: stmmac: xgmac: fix handling of DPP safety error for DMA channels
https://notcve.org/view.php?id=CVE-2024-26684
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac: fix handling of DPP safety error for DMA channels Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") checks and reports safety errors, but leaves the Data Path Parity Errors for each channel in DMA unhandled at all, lead to a storm of interrupt. Fix it by checking and clearing the DMA_DPP_Interrupt_Status register. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: xgmac: corrige el manejo del error de seguridad DPP para canales DMA. El commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") verifica e informa errores de seguridad, pero deja sin controlar los errores de paridad de ruta de datos para cada canal en DMA, lo que provoca una tormenta de interrupciones. Solucionelo verificando y borrando el registro DMA_DPP_Interrupt_Status. • https://git.kernel.org/stable/c/56e58d6c8a5640eb708e85866e9d243d0357ee54 https://git.kernel.org/stable/c/e9837c83befb5b852fa76425dde98a87b737df00 https://git.kernel.org/stable/c/2fc45a4631ac7837a5c497cb4f7e2115d950fc37 https://git.kernel.org/stable/c/6609e98ed82966a1b3168c142aca30f8284a7b89 https://git.kernel.org/stable/c/e42ff0844fe418c7d03a14f9f90e1b91ba119591 https://git.kernel.org/stable/c/7e0ff50131e9d1aa507be8e670d38e9300a5f5bf https://git.kernel.org/stable/c/3b48c9e258c8691c2f093ee07b1ea3764caaa1b2 https://git.kernel.org/stable/c/46eba193d04f8bd717e525eb4110f3c46 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26680 – net: atlantic: Fix DMA mapping for PTP hwts ring
https://notcve.org/view.php?id=CVE-2024-26680
In the Linux kernel, the following vulnerability has been resolved: net: atlantic: Fix DMA mapping for PTP hwts ring Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue. Trace: [ 215.351607] ------------[ cut here ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [ 215.581176] Call Trace: [ 215.583632] <TASK> [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df [ 215.594497] ? debug_dma_free_coherent+0x196/0x210 [ 215.599305] ? check_unmap+0xa6f/0x2360 [ 215.603147] ? • https://git.kernel.org/stable/c/94ad94558b0fbf18dd6fb0987540af1693157556 https://git.kernel.org/stable/c/466ceebe48cbba3f4506f165fca7111f9eb8bb12 https://git.kernel.org/stable/c/004fe5b7f59286a926a45e0cafc7870e9cdddd56 https://git.kernel.org/stable/c/e42e334c645575be5432adee224975d4f536fdb1 https://git.kernel.org/stable/c/2e7d3b67630dfd8f178c41fa2217aa00e79a5887 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26679 – inet: read sk->sk_family once in inet_recv_error()
https://notcve.org/view.php?id=CVE-2024-26679
In the Linux kernel, the following vulnerability has been resolved: inet: read sk->sk_family once in inet_recv_error() inet_recv_error() is called without holding the socket lock. IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM socket option and trigger a KCSAN warning. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: inet: lee sk->sk_family una vez en inet_recv_error() se llama a inet_recv_error() sin mantener el bloqueo del socket. El socket IPv6 podría mutar a IPv4 con la opción de socket IPV6_ADDRFORM y generar una advertencia de KCSAN. • https://git.kernel.org/stable/c/f4713a3dfad045d46afcb9c2a7d0bba288920ed4 https://git.kernel.org/stable/c/433337f9c00cac447d020922f59237273f5d92be https://git.kernel.org/stable/c/caa064c3c2394d03e289ebd6b0be5102eb8a5b40 https://git.kernel.org/stable/c/5993f121fbc01dc2d734f0ff2628009b258fb1dd https://git.kernel.org/stable/c/88081ba415224cf413101def4343d660f56d082b https://git.kernel.org/stable/c/3266e638ba5cc1165f5e6989eb8c0720f1cc4b41 https://git.kernel.org/stable/c/54538752216bf89ee88d47ad07802063a498c299 https://git.kernel.org/stable/c/4a5e31bdd3c1702b520506d9cf8c41085 •