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: 5.5EPSS: 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 • CWE-416: Use After Free •
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-26681 – netdevsim: avoid potential loop in nsim_dev_trap_report_work()
https://notcve.org/view.php?id=CVE-2024-26681
In the Linux kernel, the following vulnerability has been resolved: netdevsim: avoid potential loop in nsim_dev_trap_report_work() Many syzbot reports include the following trace [1] If nsim_dev_trap_report_work() can not grab the mutex, it should rearm itself at least one jiffie later. [1] Sending NMI from CPU 1 to CPUs 0: NMI backtrace for cpu 0 CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events nsim_dev_trap_report_work RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [inline] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [inline] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:129 [inline] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [inline] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline] RIP: 0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189 Code: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 <48> 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00 RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046 RAX: fffffbfff258af1e RBX: fffffbfff258af1f RCX: ffffffff8168eda3 RDX: fffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0 RBP: fffffbfff258af1e R08: 0000000000000000 R09: fffffbfff258af1e R10: ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002 R13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8 FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00994e078 CR3: 000000002c250000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> instrument_atomic_read include/linux/instrumented.h:68 [inline] atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline] queued_spin_is_locked include/asm-generic/qspinlock.h:57 [inline] debug_spin_unlock kernel/locking/spinlock_debug.c:101 [inline] do_raw_spin_unlock+0x53/0x230 kernel/locking/spinlock_debug.c:141 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150 [inline] _raw_spin_unlock_irqrestore+0x22/0x70 kernel/locking/spinlock.c:194 debug_object_activate+0x349/0x540 lib/debugobjects.c:726 debug_work_activate kernel/workqueue.c:578 [inline] insert_work+0x30/0x230 kernel/workqueue.c:1650 __queue_work+0x62e/0x11d0 kernel/workqueue.c:1802 __queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953 queue_delayed_work_on+0x106/0x130 kernel/workqueue.c:1989 queue_delayed_work include/linux/workqueue.h:563 [inline] schedule_delayed_work include/linux/workqueue.h:677 [inline] nsim_dev_trap_report_work+0x9c0/0xc80 drivers/net/netdevsim/dev.c:842 process_one_work+0x886/0x15d0 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x8b9/0x1290 kernel/workqueue.c:2787 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 </TASK> En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netdevsim: evita un posible bucle en nsim_dev_trap_report_work() Muchos informes de syzbot incluyen el siguiente seguimiento [1] Si nsim_dev_trap_report_work() no puede capturar el mutex, debería rearmarse al menos un santiamén después . [1] Envío de NMI desde la CPU 1 a las CPU 0: seguimiento de NMI para la CPU 0 CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 Cola de trabajo: eventos nsim_dev_trap_report_work RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [en línea] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [ en línea] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:129 [en línea] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [en línea] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [en línea] RIP: 0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189 Código: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 <48> 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00 RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046 RAX: ffffbfff258af1e RBX: ffffbfff258af1f RCX: ffffffff8168eda3 RDX: ffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0 RBP: ffffbfff258af1e R08: 00000000000000000 R09: f ffffbfff258af1e R10: ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002 R13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8 FS: 0000 000000000000(0000) GS: ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00994e078 CR3: 000000002c250000 CR 4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 00000 00000000400 Seguimiento de llamadas: < NMI> instrument_atomic_read include/linux/instrumented.h:68 [en línea] atomic_read include/linux/atomic/atomic-instrumented.h:32 [en línea] queued_spin_is_locked include/asm-generic/qspinlock.h: 57 [en línea] debug_spin_unlock kernel/locking/spinlock_debug.c:101 [en línea] do_raw_spin_unlock+0x53/0x230 kernel/locking/spinlock_debug.c:141 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150 [en línea] _raw_spin_unlock_irqrestore +0x22/0x70 núcleo /locking/spinlock.c:194 debug_object_activate+0x349/0x540 lib/debugobjects.c:726 debug_work_activate kernel/workqueue.c:578 [en línea] insert_work+0x30/0x230 kernel/workqueue.c:1650 __queue_work+0x62e/0x11d0 kernel/ workqueue.c:1802 __queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953 queue_delayed_work_on+0x106/0x130 kernel/workqueue.c:1989 queue_delayed_work include/linux/workqueue.h:563 [en línea] Schedule_delayed_work include/linux/workqueue.h :677 [en línea] nsim_dev_trap_report_work+0x9c0/0xc80 drivers/net/netdevsim/dev.c:842 Process_one_work+0x886/0x15d0 kernel/workqueue.c:2633 Process_scheduled_works kernel/workqueue.c:2706 [en línea] work_thread+0x8b9/0x1290 núcleo /workqueue.c:2787 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 • https://git.kernel.org/stable/c/012ec02ae4410207f796a9b280a60b80b6cc790a https://git.kernel.org/stable/c/0193e0660cc6689c794794b471492923cfd7bfbc https://git.kernel.org/stable/c/6eecddd9c3c8d6e3a097531cdc6d500335b35e46 https://git.kernel.org/stable/c/d91964cdada76740811b7c621239f9c407820dbc https://git.kernel.org/stable/c/ba5e1272142d051dcc57ca1d3225ad8a089f9858 •
CVSS: 4.4EPSS: 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 https://access.redhat.com/security/cve/CVE-2024-26680 https://bugzilla.redhat.com/show_bug.cgi?id=2272842 • CWE-20: Improper Input Validation •