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: 3EXPL: 0CVE-2024-26677 – rxrpc: Fix delayed ACKs to not set the reference serial number
https://notcve.org/view.php?id=CVE-2024-26677
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix delayed ACKs to not set the reference serial number Fix the construction of delayed ACKs to not set the reference serial number as they can't be used as an RTT reference. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: rxrpc: corrige los ACK retrasados para no establecer el número de serie de referencia. Se corrige la construcción de los ACK retrasados para no establecer el número de serie de referencia, ya que no se pueden usar como referencia RTT. • https://git.kernel.org/stable/c/17926a79320afa9b95df6b977b40cca6d8713cea https://git.kernel.org/stable/c/200cb50b9e154434470c8969d32474d38475acc2 https://git.kernel.org/stable/c/63719f490e6a89896e9a463d2b45e8203eab23ae https://git.kernel.org/stable/c/e7870cf13d20f56bfc19f9c3e89707c69cf104ef •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26675 – ppp_async: limit MRU to 64K
https://notcve.org/view.php?id=CVE-2024-26675
In the Linux kernel, the following vulnerability has been resolved: ppp_async: limit MRU to 64K syzbot triggered a warning [1] in __alloc_pages(): WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K") Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU) [1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events_unbound flush_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537 sp : ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001 x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0 Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline] ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ppp_async: limitar MRU a 64K syzbot activó una advertencia [1] en __alloc_pages(): WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) Willem solucionó un problema similar en el commit c0a2a1b0d631 ("ppp: limite MRU a 64K") Adopte la misma verificación de cordura para ppp_async_ioctl(PPPIOCSMRU) [1]: ADVERTENCIA: CPU: 1 PID: 11 en mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 Módulos vinculados en: CPU: 1 PID: 11 Comm: kworker/u4:0 No contaminado 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 Cola de trabajo: events_unbound flux_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537 sp: ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000 939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff8000939671 20 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 00000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9: 0000000000000001 x8: ffff800091c 91000 x7: 0000000000000000 x6: 000000000000003f x5: 00000000ffffffff x4: 0000000000000000 x3: 00000000000000020 x2: 0000000000000008 x1: 0000000000000000 x0: ffff8000939675e0 Rastreo de llamadas: __alloc_pages+0x308/ 0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [en línea] alloc_pages_node include/linux/gfp.h:261 [en línea] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub .c:3969 [en línea] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0x b8 /0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [en línea] dev_alloc_skb include/linux/skbuff.h:3248 [en línea] ppp_async_input drivers/net/ppp/ppp_async.c:863 [ en línea] ppp_asynctty_receive+0x588/0x186c controladores/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c controladores/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac controladores/tty/tty_port.c:37 recibir_buf controladores /tty /tty_buffer.c:444 [en línea] Flush_to_ldisc+0x284/0x6e4 controladores/tty/tty_buffer.c:494 Process_one_work+0x694/0x1204 kernel/workqueue.c:2633 Process_scheduled_works kernel/workqueue.c:2706 [en línea] trabajador_thread+0x938/ 0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/4fdb14ba89faff6e6969a4dffdc8e54235d6e5ed https://git.kernel.org/stable/c/56fae81633ccee307cfcb032f706bf1863a56982 https://git.kernel.org/stable/c/b06e067e93fa4b98acfd3a9f38a398ab91bbc58b https://git.kernel.org/stable/c/58fbe665b097bf7b3144da7e7b91fb27aa8d0ae3 https://git.kernel.org/stable/c/4e2c4846b2507f6dfc9bea72b7567c2693a82a16 https://git.kernel.org/stable/c/7e5ef49670766c9742ffcd9cead7cdb018268719 https://git.kernel.org/stable/c/210d938f963dddc543b07e66a79b7d8d4 • CWE-20: Improper Input Validation •
CVSS: 7.1EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26672 – drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()'
https://notcve.org/view.php?id=CVE-2024-26672
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()' Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() warn: variable dereferenced before check 'mca_funcs' (see line 368) 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev, enum amdgpu_mca_error_type type, 358 int idx, struct mca_bank_entry *entry) 359 { 360 const struct amdgpu_mca_smu_funcs *mca_funcs = adev->mca.mca_funcs; 361 int count; 362 363 switch (type) { 364 case AMDGPU_MCA_ERROR_TYPE_UE: 365 count = mca_funcs->max_ue_count; mca_funcs is dereferenced here. 366 break; 367 case AMDGPU_MCA_ERROR_TYPE_CE: 368 count = mca_funcs->max_ce_count; mca_funcs is dereferenced here. 369 break; 370 default: 371 return -EINVAL; 372 } 373 374 if (idx >= count) 375 return -EINVAL; 376 377 if (mca_funcs && mca_funcs->mca_get_mca_entry) ^^^^^^^^^ Checked too late! En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrige la variable 'mca_funcs' desreferenciada antes de la comprobación NULL en 'amdgpu_mca_smu_get_mca_entry()' Corrige lo siguiente: drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() advertencia: variable desreferenciada antes de verificar 'mca_funcs' (ver línea 368) 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev, enum amdgpu_mca_error_type type, 358 int idx, struct mca_bank_entry *entry) 359 { 360 const struct amdgpu_mca_smu_funcs *mca_funcs = adev- >mca.mca_funcs; 361 recuentos internacionales; 362 363 interruptor (tipo) { 364 caso AMDGPU_MCA_ERROR_TYPE_UE: 365 recuento = mca_funcs->max_ue_count; Aquí se elimina la referencia a mca_funcs. 366 descanso; 367 caso AMDGPU_MCA_ERROR_TYPE_CE: 368 recuento = mca_funcs->max_ce_count; Aquí se elimina la referencia a mca_funcs. 369 descanso; 370 predeterminado: 371 retorno -EINVAL; 372 } 373 374 si (idx >= recuento) 375 retorno -EINVAL; 376 377 if (mca_funcs && mca_funcs->mca_get_mca_entry) ^^^^^^^^^ ¡Comprobado demasiado tarde! • https://git.kernel.org/stable/c/7b5d58c07024516c0e81b95e98f37710cf402c53 https://git.kernel.org/stable/c/4f32504a2f85a7b40fe149436881381f48e9c0c0 https://access.redhat.com/security/cve/CVE-2024-26672 https://bugzilla.redhat.com/show_bug.cgi?id=2272814 • CWE-476: NULL Pointer Dereference •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26671 – blk-mq: fix IO hang from sbitmap wakeup race
https://notcve.org/view.php?id=CVE-2024-26671
In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix IO hang from sbitmap wakeup race In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered with the following blk_mq_get_driver_tag() in case of getting driver tag failure. Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime blk_mq_mark_tag_wait() can't get driver tag successfully. This issue can be reproduced by running the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100 --numjobs=40 --time_based --name=test \ --ioengine=libaio Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which is just fine in case of running out of tag. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: blk-mq: corrige el bloqueo de IO de la carrera de activación del mapa de bits En blk_mq_mark_tag_wait(), __add_wait_queue() se puede reordenar con el siguiente blk_mq_get_driver_tag() en caso de que se produzca un error en la etiqueta del controlador. Luego, en __sbitmap_queue_wake_up(), waitqueue_active() puede no observar al camarero agregado en blk_mq_mark_tag_wait() y no despertar nada, mientras tanto, blk_mq_mark_tag_wait() no puede obtener la etiqueta del controlador correctamente. Este problema se puede reproducir ejecutando la siguiente prueba en bucle, y se puede observar un bloqueo de fio en < 30 minutos cuando lo ejecuto en mi máquina virtual de prueba en una computadora portátil. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block /* | cabeza -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --io Depth=1 \ --runtime=100 --numjobs=40 --time_based - -name=test \ --ioengine=libaio Solucione el problema agregando una barrera explícita en blk_mq_mark_tag_wait(), lo cual está bien en caso de quedarse sin etiqueta. • https://git.kernel.org/stable/c/9525b38180e2753f0daa1a522b7767a2aa969676 https://git.kernel.org/stable/c/ecd7744a1446eb02ccc63e493e2eb6ede4ef1e10 https://git.kernel.org/stable/c/7610ba1319253225a9ba8a9d28d472fc883b4e2f https://git.kernel.org/stable/c/89e0e66682e1538aeeaa3109503473663cd24c8b https://git.kernel.org/stable/c/1d9c777d3e70bdc57dddf7a14a80059d65919e56 https://git.kernel.org/stable/c/6d8b01624a2540336a32be91f25187a433af53a0 https://git.kernel.org/stable/c/f1bc0d8163f8ee84a8d5affdf624cfad657df1d2 https://git.kernel.org/stable/c/5266caaf5660529e3da53004b8b7174ca • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •