CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-27016 – netfilter: flowtable: validate pppoe header
https://notcve.org/view.php?id=CVE-2024-27016
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: validate pppoe header Ensure there is sufficient room to access the protocol field of the PPPoe header. Validate it once before the flowtable lookup, then use a helper function to access protocol field. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: flowtable: validar encabezado pppoe Asegúrese de que haya suficiente espacio para acceder al campo de protocolo del encabezado PPPoe. Valídelo una vez antes de la búsqueda de la tabla de flujo, luego use una función auxiliar para acceder al campo de protocolo. • https://git.kernel.org/stable/c/72efd585f7144a047f7da63864284764596ccad9 https://git.kernel.org/stable/c/d06977b9a4109f8738bb276125eb6a0b772bc433 https://git.kernel.org/stable/c/8bf7c76a2a207ca2b4cfda0a279192adf27678d7 https://git.kernel.org/stable/c/a2471d271042ea18e8a6babc132a8716bb2f08b9 https://git.kernel.org/stable/c/cf366ee3bc1b7d1c76a882640ba3b3f8f1039163 https://git.kernel.org/stable/c/87b3593bed1868b2d9fe096c01bcdf0ea86cbebf https://access.redhat.com/security/cve/CVE-2024-27016 https://bugzilla.redhat.com/show_bug.cgi?id=2278264 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-27015 – netfilter: flowtable: incorrect pppoe tuple
https://notcve.org/view.php?id=CVE-2024-27015
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: incorrect pppoe tuple pppoe traffic reaching ingress path does not match the flowtable entry because the pppoe header is expected to be at the network header offset. This bug causes a mismatch in the flow table lookup, so pppoe packets enter the classical forwarding path. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: tabla de flujo: tupla de pppoe incorrecta. El tráfico de pppoe que llega a la ruta de entrada no coincide con la entrada de la tabla de flujo porque se espera que el encabezado de pppoe esté en el desplazamiento del encabezado de red. Este error provoca una discrepancia en la búsqueda de la tabla de flujo, por lo que los paquetes pppoe ingresan a la ruta de reenvío clásica. • https://git.kernel.org/stable/c/72efd585f7144a047f7da63864284764596ccad9 https://git.kernel.org/stable/c/e719b52d0c56989b0f3475a03a6d64f182c85b56 https://git.kernel.org/stable/c/f1c3c61701a0b12f4906152c1626a5de580ea3d2 https://git.kernel.org/stable/c/4ed82dd368ad883dc4284292937b882f044e625d https://git.kernel.org/stable/c/e3f078103421642fcd5f05c5e70777feb10f000d https://git.kernel.org/stable/c/6db5dc7b351b9569940cd1cf445e237c42cd6d27 •
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: 9EXPL: 0CVE-2024-27012 – netfilter: nf_tables: restore set elements when delete set fails
https://notcve.org/view.php?id=CVE-2024-27012
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: restore set elements when delete set fails From abort path, nft_mapelem_activate() needs to restore refcounters to the original state. Currently, it uses the set->ops->walk() to iterate over these set elements. The existing set iterator skips inactive elements in the next generation, this does not work from the abort path to restore the original state since it has to skip active elements instead (not inactive ones). This patch moves the check for inactive elements to the set iterator callback, then it reverses the logic for the .activate case which needs to skip active elements. Toggle next generation bit for elements when delete set command is invoked and call nft_clear() from .activate (abort) path to restore the next generation bit. The splat below shows an object in mappings memleak: [43929.457523] ------------[ cut here ]------------ [43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [...] [43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 <0f> 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 [43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246 [43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000 [43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550 [43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f [43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0 [43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002 [43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0 [43929.458114] Call Trace: [43929.458118] <TASK> [43929.458121] ? __warn+0x9f/0x1a0 [43929.458127] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458188] ? • https://git.kernel.org/stable/c/628bd3e49cba1c066228e23d71a852c23e26da73 https://git.kernel.org/stable/c/bc9f791d2593f17e39f87c6e2b3a36549a3705b1 https://git.kernel.org/stable/c/3c7ec098e3b588434a8b07ea9b5b36f04cef1f50 https://git.kernel.org/stable/c/a136b7942ad2a50de708f76ea299ccb45ac7a7f9 https://git.kernel.org/stable/c/25aa2ad37c2162be1c0bc4fe6397f7e4c13f00f8 https://git.kernel.org/stable/c/d60be2da67d172aecf866302c91ea11533eca4d9 https://git.kernel.org/stable/c/dc7cdf8cbcbf8b13de1df93f356ec04cdeef5c41 https://git.kernel.org/stable/c/164936b2fc88883341fe7a2d9c42b6902 • CWE-401: Missing Release of Memory after Effective Lifetime •