CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56660 – net/mlx5: DR, prevent potential error pointer dereference
https://notcve.org/view.php?id=CVE-2024-56660
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: DR, prevent potential error pointer dereference The dr_domain_add_vport_cap() function generally returns NULL on error but sometimes we want it to return ERR_PTR(-EBUSY) so the caller can retry. The problem here is that "ret" can be either -EBUSY or -ENOMEM and if it's and -ENOMEM then the error pointer is propogated back and eventually dereferenced in dr_ste_v0_build_src_gvmi_qpn_tag(). • https://git.kernel.org/stable/c/11a45def2e197532c46aa908dedd52bc1ee378a2 https://git.kernel.org/stable/c/61f720e801443d4e2a3c0261eda4ad8431458dca https://git.kernel.org/stable/c/325cf73a1b449fea3158ab99d03a7a717aad1618 https://git.kernel.org/stable/c/a59c61a1869ceefc65ef02886f91e8cd0062211f https://git.kernel.org/stable/c/11776cff0b563c8b8a4fa76cab620bfb633a8cb8 •
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: 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 •