CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56659 – net: lapb: increase LAPB_HEADER_LEN
https://notcve.org/view.php?id=CVE-2024-56659
In the Linux kernel, the following vulnerability has been resolved: net: lapb: increase LAPB_HEADER_LEN It is unclear if net/lapb code is supposed to be ready for 8021q. We can at least avoid crashes like the following : skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc90002ddf638 EFLAGS: 00010282 RAX: 0000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600 RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000 RBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60 R10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140 R13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016 FS: 00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_push+0xe5/0x100 net/core/skbuff.c:2636 nr_header+0x36/0x320 net/netrom/nr_dev.c:69 dev_hard_header include/linux/netdevice.h:3148 [inline] vlan_dev_hard_header+0x359/0x480 net/8021q/vlan_dev.c:83 dev_hard_header include/linux/netdevice.h:3148 [inline] lapbeth_data_transmit+0x1f6/0x2a0 drivers/net/wan/lapbether.c:257 lapb_data_transmit+0x91/0xb0 net/lapb/lapb_iface.c:447 lapb_transmit_buffer+0x168/0x1f0 net/lapb/lapb_out.c:149 lapb_establish_data_link+0x84/0xd0 lapb_device_event+0x4e0/0x670 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:8922 devinet_ioctl+0xa4e/0x1aa0 net/ipv4/devinet.c:1188 inet_ioctl+0x3d7/0x4f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x158/0x460 net/socket.c:1227 sock_ioctl+0x626/0x8e0 net/socket.c:1346 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/3aa2ef7ffd0451e8f81c249d2a2a68283c6bc700 https://git.kernel.org/stable/c/76d856f03d0290cf5392364ecdf74c15ee16b8fd https://git.kernel.org/stable/c/c21c7c1c00bcc60cf752ec491bdfd47693f4d3c7 https://git.kernel.org/stable/c/f0949199651bc87c5ed2c12a7323f441f1af6fe9 https://git.kernel.org/stable/c/03e661b5e7aa1124f24054df9ab2ee5cb2178973 https://git.kernel.org/stable/c/2b351355bbd50ae25d096785b6eb31998d2bf765 https://git.kernel.org/stable/c/a6d75ecee2bf828ac6a1b52724aba0a97 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-56658 – net: defer final 'struct net' free in netns dismantle
https://notcve.org/view.php?id=CVE-2024-56658
In the Linux kernel, the following vulnerability has been resolved: net: defer final 'struct net' free in netns dismantle Ilya reported a slab-use-after-free in dst_destroy [1] Issue is in xfrm6_net_init() and xfrm4_net_init() : They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops. But net structure might be freed before all the dst callbacks are called. So when dst_destroy() calls later : if (dst->ops->destroy) dst->ops->destroy(dst); dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed. See a relevant issue fixed in : ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") A fix is to queue the 'struct net' to be freed after one another cleanup_net() round (and existing rcu_barrier()) [1] BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112) Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0 Dec 03 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67 Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:124) print_address_description.constprop.0 (mm/kasan/report.c:378) ? dst_destroy (net/core/dst.c:112) print_report (mm/kasan/report.c:489) ? dst_destroy (net/core/dst.c:112) ? kasan_addr_to_slab (mm/kasan/common.c:37) kasan_report (mm/kasan/report.c:603) ? • https://git.kernel.org/stable/c/a8a572a6b5f2a79280d6e302cb3c1cb1fbaeb3e8 https://git.kernel.org/stable/c/3e29fa5b742479f73400468314a1c6b9cf553ee4 https://git.kernel.org/stable/c/ce43f6a650a6689551a217276fb0dcca33790425 https://git.kernel.org/stable/c/eeca98948d8c4922e6deb16bfc9ee0bd9902dbb0 https://git.kernel.org/stable/c/1bd631fc9a4515878c1bb7effd19335d2f2d87c2 https://git.kernel.org/stable/c/3267b254dc0a04dfa362a2be24573cfa6d2d78f5 https://git.kernel.org/stable/c/b7a79e51297f7b82adb687086f5cb2da446f1e40 https://git.kernel.org/stable/c/6610c7f8a8d47fd1123eed55ba8c11c24 •
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: 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 •