CVSS: 4.7EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36286 – netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()
https://notcve.org/view.php?id=CVE-2024-36286
In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu() syzbot reported that nf_reinject() could be called without rcu_read_lock() : WARNING: suspicious RCU usage 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172 stack backtrace: CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline] instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 rcu_do_batch kernel/rcu/tree.c:2196 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 </IRQ> <TASK> En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nfnetlink_queue: adquirir rcu_read_lock() en instancia_destroy_rcu() syzbot informó que se podía llamar a nf_reinject() sin rcu_read_lock() : ADVERTENCIA: uso sospechoso de RCU 6.9.0-rc7-syzkaller -02060-g5c1672705a1a #0 ¡No está contaminado net/netfilter/nfnetlink_queue.c:263 uso sospechoso de rcu_dereference_check()! otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 2 bloqueos mantenidos por syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, en: rcu_lock_acquire include/linux/rcupdate.h:329 [en línea] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, en: rcu_do_batch kernel/rcu/tree.c:2190 [en línea] #0 : ffffffff8e334f60 (rcu_callback){....}-{0:0}, en: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.} -{2:2}, en: spin_lock_bh include/linux/spinlock.h:356 [en línea] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, en: nfqnl_flush net/ netfilter/nfnetlink_queue.c:405 [en línea] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, en: instancia_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172 pila backtrace: CPU: 0 PID: 13427 Comm: syz-executor.4 No contaminado 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Llamada de Google 02/04/2024 Trace: __dump_stack lib/dump_stack.c: 88 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c: 114 Lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c: 6712 nf_filt. C :323 [en línea] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [en línea] instancia_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 do_batch kernel/rcu /tree.c:2196 [en línea] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [en línea] invoke_softirq kernel/softirq .c:428 [en línea] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [en línea] r_interrupción+ 0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 • https://git.kernel.org/stable/c/9872bec773c2e8503fec480c1e8a0c732517e257 https://git.kernel.org/stable/c/8658bd777cbfcb0c13df23d0ea120e70517761b9 https://git.kernel.org/stable/c/3989b817857f4890fab9379221a9d3f52bf5c256 https://git.kernel.org/stable/c/e01065b339e323b3dfa1be217fd89e9b3208b0ab https://git.kernel.org/stable/c/25ea5377e3d2921a0f96ae2551f5ab1b36825dd4 https://git.kernel.org/stable/c/68f40354a3851df46c27be96b84f11ae193e36c5 https://git.kernel.org/stable/c/8f365564af898819a523f1a8cf5c6ce053e9f718 https://git.kernel.org/stable/c/215df6490e208bfdd5b3012f5075e7f87 • CWE-667: Improper Locking •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36281 – net/mlx5: Use mlx5_ipsec_rx_status_destroy to correctly delete status rules
https://notcve.org/view.php?id=CVE-2024-36281
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Use mlx5_ipsec_rx_status_destroy to correctly delete status rules rx_create no longer allocates a modify_hdr instance that needs to be cleaned up. The mlx5_modify_header_dealloc call will lead to a NULL pointer dereference. A leak in the rules also previously occurred since there are now two rules populated related to status. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 109907067 P4D 109907067 PUD 116890067 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 484 Comm: ip Not tainted 6.9.0-rc2-rrameshbabu+ #254 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:mlx5_modify_header_dealloc+0xd/0x70 <snip> Call Trace: <TASK> ? show_regs+0x60/0x70 ? __die+0x24/0x70 ? • https://git.kernel.org/stable/c/20af7afcd8b85a4cb413072d631bf9a6469eee3a https://git.kernel.org/stable/c/94af50c0a9bb961fe93cf0fdd14eb0883da86721 https://git.kernel.org/stable/c/b0a15cde37a8388e57573686f650a17208ae1212 https://git.kernel.org/stable/c/cc9ac559f2e21894c21ac5b0c85fb24a5cab266c https://git.kernel.org/stable/c/16d66a4fa81da07bc4ed19f4e53b87263c2f8d38 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-36270 – netfilter: tproxy: bail out if IP has been disabled on the device
https://notcve.org/view.php?id=CVE-2024-36270
In the Linux kernel, the following vulnerability has been resolved: netfilter: tproxy: bail out if IP has been disabled on the device syzbot reports: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] [..] RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62 Call Trace: nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline] nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168 __in_dev_get_rcu() can return NULL, so check for this. • https://git.kernel.org/stable/c/cc6eb433856983e91071469c4ce57accb6947ccb https://git.kernel.org/stable/c/10f0af5234dafd03d2b75233428ec3f11cf7e43d https://git.kernel.org/stable/c/07eeedafc59c45fe5de43958128542be3784764c https://git.kernel.org/stable/c/6fe5af4ff06db3d4d80e07a19356640428159f03 https://git.kernel.org/stable/c/caf3a8afb5ea00db6d5398adf148d5534615fd80 https://git.kernel.org/stable/c/570b4c52096e62fda562448f5760fd0ff06110f0 https://git.kernel.org/stable/c/819bfeca16eb9ad647ddcae25e7e12c30612147c https://git.kernel.org/stable/c/21a673bddc8fd4873c370caf9ae70ffc6 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-36244 – net/sched: taprio: extend minimum interval restriction to entire cycle too
https://notcve.org/view.php?id=CVE-2024-36244
In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: extend minimum interval restriction to entire cycle too It is possible for syzbot to side-step the restriction imposed by the blamed commit in the Fixes: tag, because the taprio UAPI permits a cycle-time different from (and potentially shorter than) the sum of entry intervals. We need one more restriction, which is that the cycle time itself must be larger than N * ETH_ZLEN bit times, where N is the number of schedule entries. This restriction needs to apply regardless of whether the cycle time came from the user or was the implicit, auto-calculated value, so we move the existing "cycle == 0" check outside the "if "(!new->cycle_time)" branch. This way covers both conditions and scenarios. Add a selftest which illustrates the issue triggered by syzbot. • https://git.kernel.org/stable/c/b5b73b26b3ca34574124ed7ae9c5ba8391a7f176 https://git.kernel.org/stable/c/83bd58952b2b8543d8c48d1453975ab47a0a7504 https://git.kernel.org/stable/c/817ff50796c5e364c879596509f83fcba194bb6f https://git.kernel.org/stable/c/34d83c3e6e97867ae061d14eb52123404aab1cbc https://git.kernel.org/stable/c/b939d1e04a90248b4cdf417b0969c270ceb992b2 https://git.kernel.org/stable/c/91f249b01fe490fce11fbb4307952ca8cce78724 https://git.kernel.org/stable/c/fb66df20a7201e60f2b13d7f95d031b31a8831d3 https://access.redhat.com/security/cve/CVE-2024-36244 • CWE-20: Improper Input Validation •
CVSS: 2.3EPSS: 0%CPEs: 8EXPL: 0CVE-2024-33621 – ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound
https://notcve.org/view.php?id=CVE-2024-33621
In the Linux kernel, the following vulnerability has been resolved: ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path. WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70 Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:sk_mc_loop+0x2d/0x70 Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212 RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001 RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000 RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00 R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000 R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000 FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? __warn (kernel/panic.c:693) ? sk_mc_loop (net/core/sock.c:760) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:239) ? • https://git.kernel.org/stable/c/2ad7bf3638411cb547f2823df08166c13ab04269 https://git.kernel.org/stable/c/0049a623dfbbb49888de7f0c2f33a582b5ead989 https://git.kernel.org/stable/c/54768bacfde60e8e4757968d79f8726711dd2cf5 https://git.kernel.org/stable/c/1abbf079da59ef559d0ab4219d2a0302f7970761 https://git.kernel.org/stable/c/183c4b416454b9983dc1b8aa0022b748911adc48 https://git.kernel.org/stable/c/cb53706a3403ba67f4040b2a82d9cf79e11b1a48 https://git.kernel.org/stable/c/54213c09801e0bd2549ac42961093be36f65a7d0 https://git.kernel.org/stable/c/13c4543db34e0da5a7d2f550b6262d860 • CWE-20: Improper Input Validation •