CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2024-56651 – can: hi311x: hi3110_can_ist(): fix potential use-after-free
https://notcve.org/view.php?id=CVE-2024-56651
In the Linux kernel, the following vulnerability has been resolved: can: hi311x: hi3110_can_ist(): fix potential use-after-free The commit a22bd630cfff ("can: hi311x: do not report txerr and rxerr during bus-off") removed the reporting of rxerr and txerr even in case of correct operation (i. e. not bus-off). The error count information added to the CAN frame after netif_rx() is a potential use after free, since there is no guarantee that the skb is in the same state. It might be freed or reused. Fix the issue by postponing the netif_rx() call in case of txerr and rxerr reporting. • https://git.kernel.org/stable/c/a22bd630cfff496b270211745536e50e98eb3a45 https://git.kernel.org/stable/c/303733fdab728d34708014b3096dc69ebae6e531 https://git.kernel.org/stable/c/410054f1cf75378a6f009359e5952a240102a1a2 https://git.kernel.org/stable/c/d20bf7e76136fd4c1e47502a1f5773f2290013ed https://git.kernel.org/stable/c/22e382d47de09e865a9214cc5c9f99256e65deaa https://git.kernel.org/stable/c/dcfcd5fc999b1eb7946de1fd031bc3aaf224c5ae https://git.kernel.org/stable/c/330b0ac34beec4fef8b002549af5bc6d0b6f0836 https://git.kernel.org/stable/c/f3d865a6b791abbc874739ed702ae64ad •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56650 – netfilter: x_tables: fix LED ID check in led_tg_check()
https://notcve.org/view.php?id=CVE-2024-56650
In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: fix LED ID check in led_tg_check() Syzbot has reported the following BUG detected by KASAN: BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70 Read of size 1 at addr ffff8881022da0c8 by task repro/5879 ... Call Trace: <TASK> dump_stack_lvl+0x241/0x360 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? _printk+0xd5/0x120 ? __virt_addr_valid+0x183/0x530 ? • https://git.kernel.org/stable/c/268cb38e1802db560c73167e643f14a3dcb4b07c https://git.kernel.org/stable/c/147a42bb02de8735cb08476be6d0917987d022c2 https://git.kernel.org/stable/c/ad28612ebae1fcc1104bd432e99e99d87f6bfe09 https://git.kernel.org/stable/c/36a9d94dac28beef6b8abba46ba8874320d3e800 https://git.kernel.org/stable/c/ab9916321c95f5280b72b4c5055e269f98627efe https://git.kernel.org/stable/c/a9bcc0b70d9baf3ff005874489a0dc9d023b54c3 https://git.kernel.org/stable/c/c40c96d98e536fc1daaa125c2332b988615e30a4 https://git.kernel.org/stable/c/04317f4eb2aad312ad85c1a17ad81fe75 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-56649 – net: enetc: Do not configure preemptible TCs if SIs do not support
https://notcve.org/view.php?id=CVE-2024-56649
In the Linux kernel, the following vulnerability has been resolved: net: enetc: Do not configure preemptible TCs if SIs do not support Both ENETC PF and VF drivers share enetc_setup_tc_mqprio() to configure MQPRIO. And enetc_setup_tc_mqprio() calls enetc_change_preemptible_tcs() to configure preemptible TCs. However, only PF is able to configure preemptible TCs. Because only PF has related registers, while VF does not have these registers. So for VF, its hw->port pointer is NULL. • https://git.kernel.org/stable/c/827145392a4aad635b93e5235b7d7fecc2fa31c7 https://git.kernel.org/stable/c/66127f0d1ecf00604aeab71132bde398fd9ec7c9 https://git.kernel.org/stable/c/b718b68a9964181e24d15138a09ce95785a19002 https://git.kernel.org/stable/c/b2420b8c81ec674552d00c55d46245e5c184b260 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56648 – net: hsr: avoid potential out-of-bound access in fill_frame_info()
https://notcve.org/view.php?id=CVE-2024-56648
In the Linux kernel, the following vulnerability has been resolved: net: hsr: avoid potential out-of-bound access in fill_frame_info() syzbot is able to feed a packet with 14 bytes, pretending it is a vlan one. Since fill_frame_info() is relying on skb->mac_len already, extend the check to cover this case. BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 fill_frame_info net/hsr/hsr_forward.c:709 [inline] hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606 __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434 dev_queue_xmit include/linux/netdevice.h:3168 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881 packet_alloc_skb net/packet/af_packet.c:2995 [inline] packet_snd net/packet/af_packet.c:3089 [inline] packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f • https://git.kernel.org/stable/c/f6442ee08fe66c8e45c4f246531a2aaf4f17a7a7 https://git.kernel.org/stable/c/48b491a5cc74333c4a6a82fe21cea42c055a3b0b https://git.kernel.org/stable/c/4ffd1d4a6b306ff69cbe412d2c54d2dd349ff436 https://git.kernel.org/stable/c/aa632691c722a123e47ccd05a3afdd5f87a36061 https://git.kernel.org/stable/c/c6e778901d0055356c4fb223058364cae731494a https://git.kernel.org/stable/c/6bb5c8ebc99f0671dbd3c9408ebaf935c3951186 https://git.kernel.org/stable/c/3c215663b3e27a3b08cefcaea623ff54c70c8035 https://git.kernel.org/stable/c/7ea527fbd7b94d0bee64a0a7e98279bcc •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-56647 – net: Fix icmp host relookup triggering ip_rt_bug
https://notcve.org/view.php?id=CVE-2024-56647
In the Linux kernel, the following vulnerability has been resolved: net: Fix icmp host relookup triggering ip_rt_bug arp link failure may trigger ip_rt_bug while xfrm enabled, call trace is: WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20 Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:ip_rt_bug+0x14/0x20 Call Trace: <IRQ> ip_send_skb+0x14/0x40 __icmp_send+0x42d/0x6a0 ipv4_link_failure+0xe2/0x1d0 arp_error_report+0x3c/0x50 neigh_invalidate+0x8d/0x100 neigh_timer_handler+0x2e1/0x330 call_timer_fn+0x21/0x120 __run_timer_base.part.0+0x1c9/0x270 run_timer_softirq+0x4c/0x80 handle_softirqs+0xac/0x280 irq_exit_rcu+0x62/0x80 sysvec_apic_timer_interrupt+0x77/0x90 The script below reproduces this scenario: ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \ dir out priority 0 ptype main flag localok icmp ip l a veth1 type veth ip a a 192.168.141.111/24 dev veth0 ip l s veth0 up ping 192.168.141.155 -c 1 icmp_route_lookup() create input routes for locally generated packets while xfrm relookup ICMP traffic.Then it will set input route (dst->out = ip_rt_bug) to skb for DESTUNREACH. For ICMP err triggered by locally generated packets, dst->dev of output route is loopback. Generally, xfrm relookup verification is not required on loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1). Skip icmp relookup for locally generated packets to fix it. • https://git.kernel.org/stable/c/8b7817f3a959ed99d7443afc12f78a7e1fcc2063 https://git.kernel.org/stable/c/9545011e7b2a8fc0cbd6e387a09f12cd41d7d82f https://git.kernel.org/stable/c/c44daa7e3c73229f7ac74985acb8c7fb909c4e0a •