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: 3EXPL: 0CVE-2024-56657 – ALSA: control: Avoid WARN() for symlink errors
https://notcve.org/view.php?id=CVE-2024-56657
In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Avoid WARN() for symlink errors Using WARN() for showing the error of symlink creations don't give more information than telling that something goes wrong, since the usual code path is a lregister callback from each control element creation. More badly, the use of WARN() rather confuses fuzzer as if it were serious issues. This patch downgrades the warning messages to use the normal dev_err() instead of WARN(). For making it clearer, add the function name to the prefix, too. • https://git.kernel.org/stable/c/a135dfb5de1501327895729b4f513370d2555b4d https://git.kernel.org/stable/c/d5a1ca7b59804d6779644001a878ed925a4688ca https://git.kernel.org/stable/c/36c0764474b637bbee498806485bed524cad486b https://git.kernel.org/stable/c/b2e538a9827dd04ab5273bf4be8eb2edb84357b0 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-56656 – bnxt_en: Fix aggregation ID mask to prevent oops on 5760X chips
https://notcve.org/view.php?id=CVE-2024-56656
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix aggregation ID mask to prevent oops on 5760X chips The 5760X (P7) chip's HW GRO/LRO interface is very similar to that of the previous generation (5750X or P5). However, the aggregation ID fields in the completion structures on P7 have been redefined from 16 bits to 12 bits. The freed up 4 bits are redefined for part of the metadata such as the VLAN ID. The aggregation ID mask was not modified when adding support for P7 chips. Including the extra 4 bits for the aggregation ID can potentially cause the driver to store or fetch the packet header of GRO/LRO packets in the wrong TPA buffer. • https://git.kernel.org/stable/c/13d2d3d381ee9844f89bd436ab0f44204660027e https://git.kernel.org/stable/c/fe9274027697c69c1430dc7ee568f82b331ef972 https://git.kernel.org/stable/c/24c6843b7393ebc80962b59d7ae71af91bf0dcc1 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56655 – netfilter: nf_tables: do not defer rule destruction via call_rcu
https://notcve.org/view.php?id=CVE-2024-56655
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not defer rule destruction via call_rcu nf_tables_chain_destroy can sleep, it can't be used from call_rcu callbacks. Moreover, nf_tables_rule_release() is only safe for error unwinding, while transaction mutex is held and the to-be-desroyed rule was not exposed to either dataplane or dumps, as it deactives+frees without the required synchronize_rcu() in-between. nft_rule_expr_deactivate() callbacks will change ->use counters of other chains/sets, see e.g. nft_lookup .deactivate callback, these must be serialized via transaction mutex. Also add a few lockdep asserts to make this more explicit. Calling synchronize_rcu() isn't ideal, but fixing this without is hard and way more intrusive. As-is, we can get: WARNING: .. net/netfilter/nf_tables_api.c:5515 nft_set_destroy+0x.. Workqueue: events nf_tables_trans_destroy_work RIP: 0010:nft_set_destroy+0x3fe/0x5c0 Call Trace: <TASK> nf_tables_trans_destroy_work+0x6b7/0xad0 process_one_work+0x64a/0xce0 worker_thread+0x613/0x10d0 In case the synchronize_rcu becomes an issue, we can explore alternatives. One way would be to allocate nft_trans_rule objects + one nft_trans_chain object, deactivate the rules + the chain and then defer the freeing to the nft destroy workqueue. We'd still need to keep the synchronize_rcu path as a fallback to handle -ENOMEM corner cases though. • https://git.kernel.org/stable/c/bfd05c68e4c6320304e9f371ffa356b6e4b9cc53 https://git.kernel.org/stable/c/c03d278fdf35e73dd0ec543b9b556876b9d9a8dc https://git.kernel.org/stable/c/cb401e5799e0acacb405f2128097e9c4ccf82f8a https://git.kernel.org/stable/c/27f0574253f6c24c8ee4e3f0a685b75ed3a256ed https://git.kernel.org/stable/c/7cf0bd232b565d9852cb25fd094f77254773e048 https://git.kernel.org/stable/c/b04df3da1b5c6f6dc7cdccc37941740c078c4043 •