CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-27014 – net/mlx5e: Prevent deadlock while disabling aRFS
https://notcve.org/view.php?id=CVE-2024-27014
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Prevent deadlock while disabling aRFS When disabling aRFS under the `priv->state_lock`, any scheduled aRFS works are canceled using the `cancel_work_sync` function, which waits for the work to end if it has already started. However, while waiting for the work handler, the handler will try to acquire the `state_lock` which is already acquired. The worker acquires the lock to delete the rules if the state is down, which is not the worker's responsibility since disabling aRFS deletes the rules. Add an aRFS state variable, which indicates whether the aRFS is enabled and prevent adding rules when the aRFS is disabled. Kernel log: ====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I ------------------------------------------------------ ethtool/386089 is trying to acquire lock: ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0 but task is already holding lock: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 -> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4e other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); *** DEADLOCK *** 3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core] stack backtrace: CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? • https://git.kernel.org/stable/c/45bf454ae88414e80b80979ebb2c22bd66ea7d1b https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693 https://access.redhat.com/security/cve/CVE-2024-27014 https://bugzilla.redhat.com/show_bug.cgi?id=2278268 • CWE-667: Improper Locking •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-27013 – tun: limit printing rate when illegal packet received by tun dev
https://notcve.org/view.php?id=CVE-2024-27013
In the Linux kernel, the following vulnerability has been resolved: tun: limit printing rate when illegal packet received by tun dev vhost_worker will call tun call backs to receive packets. If too many illegal packets arrives, tun_do_read will keep dumping packet contents. When console is enabled, it will costs much more cpu time to dump packet and soft lockup will be detected. net_ratelimit mechanism can be used to limit the dumping rate. PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e #3 [fffffe00003fced0] do_nmi at ffffffff8922660d #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07 #12 [ffffa65531497b68] printk at ffffffff89318306 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun] #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net] #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost] #18 [ffffa65531497f10] kthread at ffffffff892d2e72 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tun: limita la velocidad de impresión cuando el paquete ilegal recibido por tun dev vhost_worker llamará a tun para recibir paquetes. Si llegan demasiados paquetes ilegales, tun_do_read seguirá descargando el contenido de los paquetes. Cuando la consola está habilitada, le costará mucho más tiempo a la CPU volcar el paquete y se detectará un bloqueo suave. El mecanismo net_ratelimit se puede utilizar para limitar la tasa de dumping. • https://git.kernel.org/stable/c/ef3db4a5954281bc1ea49a4739c88eaea091dc71 https://git.kernel.org/stable/c/68459b8e3ee554ce71878af9eb69659b9462c588 https://git.kernel.org/stable/c/4b0dcae5c4797bf31c63011ed62917210d3fdac3 https://git.kernel.org/stable/c/14cdb43dbc827e18ac7d5b30c5b4c676219f1421 https://git.kernel.org/stable/c/a50dbeca28acf7051dfa92786b85f704c75db6eb https://git.kernel.org/stable/c/62e27ef18eb4f0d33bbae8e9ef56b99696a74713 https://git.kernel.org/stable/c/40f4ced305c6c47487d3cd8da54676e2acc1a6ad https://git.kernel.org/stable/c/52854101180beccdb9dc2077a3bea31b6 • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-27010 – net/sched: Fix mirred deadlock on device recursion
https://notcve.org/view.php?id=CVE-2024-27010
In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix mirred deadlock on device recursion When the mirred action is used on a classful egress qdisc and a packet is mirrored or redirected to self we hit a qdisc lock deadlock. See trace below. [..... other info removed for brevity....] [ 82.890906] [ 82.890906] ============================================ [ 82.890906] WARNING: possible recursive locking detected [ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W [ 82.890906] -------------------------------------------- [ 82.890906] ping/418 is trying to acquire lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] but task is already holding lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] other info that might help us debug this: [ 82.890906] Possible unsafe locking scenario: [ 82.890906] [ 82.890906] CPU0 [ 82.890906] ---- [ 82.890906] lock(&sch->q.lock); [ 82.890906] lock(&sch->q.lock); [ 82.890906] [ 82.890906] *** DEADLOCK *** [ 82.890906] [..... other info removed for brevity....] Example setup (eth0->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0 Another example(eth0->eth1->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1 tc qdisc add dev eth1 root handle 1: htb default 30 tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0 We fix this by adding an owner field (CPU id) to struct Qdisc set after root qdisc is entered. When the softirq enters it a second time, if the qdisc owner is the same CPU, the packet is dropped to break the loop. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/sched: corrige el punto muerto reflejado en la recursividad del dispositivo Cuando la acción reflejada se utiliza en una qdisc de salida con clase y un paquete se refleja o redirige a uno mismo, llegamos a un punto muerto de bloqueo de qdisc. Vea el rastro a continuación. [..... otra información eliminada por brevedad....] [ 82.890906] [ 82.890906] ============================= ================ [82.890906] ADVERTENCIA: posible bloqueo recursivo detectado [82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Contaminado: GW [82.890906] ----- --------------------------------------- [ 82.890906] ping/418 está intentando adquirir el bloqueo : [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, en: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] pero la tarea ya mantiene el bloqueo: [ 82.890906] 88006994110 (&sch->q.lock){+.-.}-{3:3}, en: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] otra información que podría ayudarnos a depurar esto: [ 82.890906] Posible escenario de bloqueo inseguro : [ 82.890906] [ 82.890906] CPU0 [ 82.890906] ---- [ 82.890906] bloqueo(&sch->q.lock); [ 82.890906] bloqueo(&sch->q.lock); [ 82.890906] [ 82.890906] *** DEADLOCK *** [ 82.890906] [..... otra información eliminada por brevedad....] Ejemplo de configuración (eth0->eth0) para recrear tc qdisc agregar dev eth0 identificador raíz 1 : htb default 30 tc filter add dev eth0 handle 1: protocolo ip prio 2 matchall \ action mirred egress redirigir dev eth0 Otro ejemplo (eth0->eth1->eth0) para recrear tc qdisc add dev eth0 root handle 1: htb default 30 tc filtro agregar dev eth0 identificador 1: protocolo ip prio 2 matchall \ acción redirección de salida reflejada dev eth1 tc qdisc agregar dev eth1 identificador raíz 1: htb predeterminado 30 tc filtro agregar dev eth1 identificador 1: protocolo ip prio 2 matchall \ acción duplicada redirección de salida dev eth0 Solucionamos esto agregando un campo de propietario (ID de CPU) a la estructura Qdisc establecida después de ingresar la qdisc raíz. • https://git.kernel.org/stable/c/e578d9c02587d57bfa7b560767c698a668a468c6 https://git.kernel.org/stable/c/e6b90468da4dae2281a6e381107f411efb48b0ef https://git.kernel.org/stable/c/0f022d32c3eca477fbf79a205243a6123ed0fe11 https://access.redhat.com/security/cve/CVE-2024-27010 https://bugzilla.redhat.com/show_bug.cgi?id=2278279 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-27008 – drm: nv04: Fix out of bounds access
https://notcve.org/view.php?id=CVE-2024-27008
In the Linux kernel, the following vulnerability has been resolved: drm: nv04: Fix out of bounds access When Output Resource (dcb->or) value is assigned in fabricate_dcb_output(), there may be out of bounds access to dac_users array in case dcb->or is zero because ffs(dcb->or) is used as index there. The 'or' argument of fabricate_dcb_output() must be interpreted as a number of bit to set, not value. Utilize macros from 'enum nouveau_or' in calls instead of hardcoding. Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm: nv04: corregir el acceso fuera de los límites Cuando se asigna el valor del recurso de salida (dcb->or) en fabricate_dcb_output(), puede haber acceso fuera de los límites a la matriz dac_users en caso de que dcb->or es cero porque ffs(dcb->or) se usa como índice allí. El argumento 'o' de fabricate_dcb_output() debe interpretarse como un número de bits a configurar, no como un valor. Utilice macros de 'enum nouveau_or' en las llamadas en lugar de codificarlas. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. • https://git.kernel.org/stable/c/2e5702aff39532662198459726c624d5eadbdd78 https://git.kernel.org/stable/c/c2b97f26f081ceec3298151481687071075a25cb https://git.kernel.org/stable/c/5050ae879a828d752b439e3827aac126709da6d1 https://git.kernel.org/stable/c/097c7918fcfa1dee233acfd1f3029f00c3bc8062 https://git.kernel.org/stable/c/df0991da7db846f7fa4ec6740350f743d3b69b04 https://git.kernel.org/stable/c/5fd4b090304e450aa0e7cc9cc2b4873285c6face https://git.kernel.org/stable/c/6690cc2732e2a8d0eaca44dcbac032a4b0148042 https://git.kernel.org/stable/c/26212da39ee14a52c76a202c6ae5153a8 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-27001 – comedi: vmk80xx: fix incomplete endpoint checking
https://notcve.org/view.php?id=CVE-2024-27001
In the Linux kernel, the following vulnerability has been resolved: comedi: vmk80xx: fix incomplete endpoint checking While vmk80xx does have endpoint checking implemented, some things can fall through the cracks. Depending on the hardware model, URBs can have either bulk or interrupt type, and current version of vmk80xx_find_usb_endpoints() function does not take that fully into account. While this warning does not seem to be too harmful, at the very least it will crash systems with 'panic_on_warn' set on them. Fix the issue found by Syzkaller [1] by somewhat simplifying the endpoint checking process with usb_find_common_endpoints() and ensuring that only expected endpoint types are present. This patch has not been tested on real hardware. [1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59 vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline] vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818 comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067 usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399 ... Similar issue also found by Syzkaller: En el kernel de Linux, se resolvió la siguiente vulnerabilidad: comedi: vmk80xx: corrige la verificación de endpoints incompleta Si bien vmk80xx tiene implementada la verificación de endpoints, algunas cosas pueden pasar desapercibidas. Dependiendo del modelo de hardware, las URB pueden tener un tipo masivo o de interrupción, y la versión actual de la función vmk80xx_find_usb_endpoints() no lo tiene completamente en cuenta. • https://git.kernel.org/stable/c/49253d542cc0f5f771dc254d248162a2a666649d https://git.kernel.org/stable/c/3a63ae0348d990e137cca04eced5b08379969ea9 https://git.kernel.org/stable/c/a3b8ae7e9297dd453f2977b011c5bc75eb20e71b https://git.kernel.org/stable/c/f15370e315976198f338b41611f37ce82af6cf54 https://git.kernel.org/stable/c/b0b268eeb087e324ef3ea71f8e6cabd07630517f https://git.kernel.org/stable/c/ac882d6b21bffecb57bcc4486701239eef5aa67b https://git.kernel.org/stable/c/59f33af9796160f851641d960bd93937f282c696 https://git.kernel.org/stable/c/6ec3514a7d35ad9cfab600187612c29f6 •