Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/cio: Ensure the copied buf is NUL terminated<br /> <br /> Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from<br /> userspace to that buffer. Later, we use scanf on this buffer but we don&amp;#39;t<br /> ensure that the string is terminated inside the buffer, this can lead to<br /> OOB read when using scanf. Fix this issue by using memdup_user_nul instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal/debugfs: Prevent use-after-free from occurring after cdev removal<br /> <br /> Since thermal_debug_cdev_remove() does not run under cdev-&gt;lock, it can<br /> run in parallel with thermal_debug_cdev_state_update() and it may free<br /> the struct thermal_debugfs object used by the latter after it has been<br /> checked against NULL.<br /> <br /> If that happens, thermal_debug_cdev_state_update() will access memory<br /> that has been freed already causing the kernel to crash.<br /> <br /> Address this by using cdev-&gt;lock in thermal_debug_cdev_remove() around<br /> the cdev-&gt;debugfs value check (in case the same cdev is removed at the<br /> same time in two different threads) and its reset to NULL.<br /> <br /> Cc :6.8+ # 6.8+

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: ensure the copied buf is NUL terminated<br /> <br /> Currently, we allocate a count-sized kernel buffer and copy count bytes<br /> from userspace to that buffer. Later, we use sscanf on this buffer but we<br /> don&amp;#39;t ensure that the string is terminated inside the buffer, this can lead<br /> to OOB read when using sscanf. Fix this issue by using memdup_user_nul<br /> instead of memdup_user.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi/unaccepted: touch soft lockup during memory accept<br /> <br /> Commit 50e782a86c98 ("efi/unaccepted: Fix soft lockups caused by<br /> parallel memory acceptance") has released the spinlock so other CPUs can<br /> do memory acceptance in parallel and not triggers softlockup on other<br /> CPUs.<br /> <br /> However the softlock up was intermittent shown up if the memory of the<br /> TD guest is large, and the timeout of softlockup is set to 1 second:<br /> <br /> RIP: 0010:_raw_spin_unlock_irqrestore<br /> Call Trace:<br /> ? __hrtimer_run_queues<br /> <br /> ? hrtimer_interrupt<br /> ? watchdog_timer_fn<br /> ? __sysvec_apic_timer_interrupt<br /> ? __pfx_watchdog_timer_fn<br /> ? sysvec_apic_timer_interrupt<br /> <br /> ? __hrtimer_run_queues<br /> <br /> ? hrtimer_interrupt<br /> ? asm_sysvec_apic_timer_interrupt<br /> ? _raw_spin_unlock_irqrestore<br /> ? __sysvec_apic_timer_interrupt<br /> ? sysvec_apic_timer_interrupt<br /> accept_memory<br /> try_to_accept_memory<br /> do_huge_pmd_anonymous_page<br /> get_page_from_freelist<br /> __handle_mm_fault<br /> __alloc_pages<br /> __folio_alloc<br /> ? __tdx_hypercall<br /> handle_mm_fault<br /> vma_alloc_folio<br /> do_user_addr_fault<br /> do_huge_pmd_anonymous_page<br /> exc_page_fault<br /> ? __do_huge_pmd_anonymous_page<br /> asm_exc_page_fault<br /> __handle_mm_fault<br /> <br /> When the local irq is enabled at the end of accept_memory(), the<br /> softlockup detects that the watchdog on single CPU has not been fed for<br /> a while. That is to say, even other CPUs will not be blocked by<br /> spinlock, the current CPU might be stunk with local irq disabled for a<br /> while, which hurts not only nmi watchdog but also softlockup.<br /> <br /> Chao Gao pointed out that the memory accept could be time costly and<br /> there was similar report before. Thus to avoid any softlocup detection<br /> during this stage, give the softlockup a flag to skip the timeout check<br /> at the end of accept_memory(), by invoking touch_softlockup_watchdog().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xdp: use flags field to disambiguate broadcast redirect<br /> <br /> When redirecting a packet using XDP, the bpf_redirect_map() helper will set<br /> up the redirect destination information in struct bpf_redirect_info (using<br /> the __bpf_xdp_redirect_map() helper function), and the xdp_do_redirect()<br /> function will read this information after the XDP program returns and pass<br /> the frame on to the right redirect destination.<br /> <br /> When using the BPF_F_BROADCAST flag to do multicast redirect to a whole<br /> map, __bpf_xdp_redirect_map() sets the &amp;#39;map&amp;#39; pointer in struct<br /> bpf_redirect_info to point to the destination map to be broadcast. And<br /> xdp_do_redirect() reacts to the value of this map pointer to decide whether<br /> it&amp;#39;s dealing with a broadcast or a single-value redirect. However, if the<br /> destination map is being destroyed before xdp_do_redirect() is called, the<br /> map pointer will be cleared out (by bpf_clear_redirect_map()) without<br /> waiting for any XDP programs to stop running. This causes xdp_do_redirect()<br /> to think that the redirect was to a single target, but the target pointer<br /> is also NULL (since broadcast redirects don&amp;#39;t have a single target), so<br /> this causes a crash when a NULL pointer is passed to dev_map_enqueue().<br /> <br /> To fix this, change xdp_do_redirect() to react directly to the presence of<br /> the BPF_F_BROADCAST flag in the &amp;#39;flags&amp;#39; value in struct bpf_redirect_info<br /> to disambiguate between a single-target and a broadcast redirect. And only<br /> read the &amp;#39;map&amp;#39; pointer if the broadcast flag is set, aborting if that has<br /> been cleared out in the meantime. This prevents the crash, while keeping<br /> the atomic (cmpxchg-based) clearing of the map pointer itself, and without<br /> adding any more checks in the non-broadcast fast path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue<br /> <br /> Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which<br /> syzbot reported [1].<br /> <br /> [1]<br /> BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue<br /> <br /> write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1:<br /> sk_psock_stop_verdict net/core/skmsg.c:1257 [inline]<br /> sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843<br /> sk_psock_put include/linux/skmsg.h:459 [inline]<br /> sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648<br /> unix_release+0x4b/0x80 net/unix/af_unix.c:1048<br /> __sock_release net/socket.c:659 [inline]<br /> sock_close+0x68/0x150 net/socket.c:1421<br /> __fput+0x2c1/0x660 fs/file_table.c:422<br /> __fput_sync+0x44/0x60 fs/file_table.c:507<br /> __do_sys_close fs/open.c:1556 [inline]<br /> __se_sys_close+0x101/0x1b0 fs/open.c:1541<br /> __x64_sys_close+0x1f/0x30 fs/open.c:1541<br /> do_syscall_64+0xd3/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> <br /> read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0:<br /> sk_psock_data_ready include/linux/skmsg.h:464 [inline]<br /> sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555<br /> sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606<br /> sk_psock_verdict_apply net/core/skmsg.c:1008 [inline]<br /> sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202<br /> unix_read_skb net/unix/af_unix.c:2546 [inline]<br /> unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682<br /> sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223<br /> unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x140/0x180 net/socket.c:745<br /> ____sys_sendmsg+0x312/0x410 net/socket.c:2584<br /> ___sys_sendmsg net/socket.c:2638 [inline]<br /> __sys_sendmsg+0x1e9/0x280 net/socket.c:2667<br /> __do_sys_sendmsg net/socket.c:2676 [inline]<br /> __se_sys_sendmsg net/socket.c:2674 [inline]<br /> __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674<br /> do_syscall_64+0xd3/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> <br /> value changed: 0xffffffff83d7feb0 -&gt; 0x0000000000000000<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024<br /> <br /> Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer<br /> dereference in sk_psock_verdict_data_ready()") fixed one NULL pointer<br /> similarly due to no protection of saved_data_ready. Here is another<br /> different caller causing the same issue because of the same reason. So<br /> we should protect it with sk_callback_lock read lock because the writer<br /> side in the sk_psock_drop() uses "write_lock_bh(&amp;sk-&gt;sk_callback_lock);".<br /> <br /> To avoid errors that could happen in future, I move those two pairs of<br /> lock into the sk_psock_data_ready(), which is suggested by John Fastabend.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs: Handle error of rpc_proc_register() in nfs_net_init().<br /> <br /> syzkaller reported a warning [0] triggered while destroying immature<br /> netns.<br /> <br /> rpc_proc_register() was called in init_nfs_fs(), but its error<br /> has been ignored since at least the initial commit 1da177e4c3f4<br /> ("Linux-2.6.12-rc2").<br /> <br /> Recently, commit d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfs<br /> in net namespaces") converted the procfs to per-netns and made<br /> the problem more visible.<br /> <br /> Even when rpc_proc_register() fails, nfs_net_init() could succeed,<br /> and thus nfs_net_exit() will be called while destroying the netns.<br /> <br /> Then, remove_proc_entry() will be called for non-existing proc<br /> directory and trigger the warning below.<br /> <br /> Let&amp;#39;s handle the error of rpc_proc_register() properly in nfs_net_init().<br /> <br /> [0]:<br /> name &amp;#39;nfs&amp;#39;<br /> WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711<br /> Modules linked in:<br /> CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711<br /> Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb<br /> RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c<br /> RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc<br /> R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8<br /> FS: 00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310<br /> nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438<br /> ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170<br /> setup_net+0x46c/0x660 net/core/net_namespace.c:372<br /> copy_net_ns+0x244/0x590 net/core/net_namespace.c:505<br /> create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110<br /> unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228<br /> ksys_unshare+0x342/0x760 kernel/fork.c:3322<br /> __do_sys_unshare kernel/fork.c:3393 [inline]<br /> __se_sys_unshare kernel/fork.c:3391 [inline]<br /> __x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x46/0x4e<br /> RIP: 0033:0x7f30d0febe5d<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110<br /> RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600<br /> RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002<br /> R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: core: reject skb_copy(_expand) for fraglist GSO skbs<br /> <br /> SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become<br /> invalid. Return NULL if such an skb is passed to skb_copy or<br /> skb_copy_expand, in order to prevent a crash on a potential later<br /> call to skb_gso_segment.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nsh: Restore skb-&gt;{protocol,data,mac_header} for outer header in nsh_gso_segment().<br /> <br /> syzbot triggered various splats (see [0] and links) by a crafted GSO<br /> packet of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:<br /> <br /> ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP<br /> <br /> NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner<br /> protocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls<br /> skb_mac_gso_segment() to invoke inner protocol GSO handlers.<br /> <br /> nsh_gso_segment() does the following for the original skb before<br /> calling skb_mac_gso_segment()<br /> <br /> 1. reset skb-&gt;network_header<br /> 2. save the original skb-&gt;{mac_heaeder,mac_len} in a local variable<br /> 3. pull the NSH header<br /> 4. resets skb-&gt;mac_header<br /> 5. set up skb-&gt;mac_len and skb-&gt;protocol for the inner protocol.<br /> <br /> and does the following for the segmented skb<br /> <br /> 6. set ntohs(ETH_P_NSH) to skb-&gt;protocol<br /> 7. push the NSH header<br /> 8. restore skb-&gt;mac_header<br /> 9. set skb-&gt;mac_header + mac_len to skb-&gt;network_header<br /> 10. restore skb-&gt;mac_len<br /> <br /> There are two problems in 6-7 and 8-9.<br /> <br /> (a)<br /> After 6 &amp; 7, skb-&gt;data points to the NSH header, so the outer header<br /> (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev.<br /> <br /> Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH),<br /> skb_pull() in the first nsh_gso_segment() will make skb-&gt;data point<br /> to the middle of the outer NSH or Ethernet header because the Ethernet<br /> header is not pulled by the second nsh_gso_segment().<br /> <br /> (b)<br /> While restoring skb-&gt;{mac_header,network_header} in 8 &amp; 9,<br /> nsh_gso_segment() does not assume that the data in the linear<br /> buffer is shifted.<br /> <br /> However, udp6_ufo_fragment() could shift the data and change<br /> skb-&gt;mac_header accordingly as demonstrated by syzbot.<br /> <br /> If this happens, even the restored skb-&gt;mac_header points to<br /> the middle of the outer header.<br /> <br /> It seems nsh_gso_segment() has never worked with outer headers so far.<br /> <br /> At the end of nsh_gso_segment(), the outer header must be restored for<br /> the segmented skb, instead of the NSH header.<br /> <br /> To do that, let&amp;#39;s calculate the outer header position relatively from<br /> the inner header and set skb-&gt;{data,mac_header,protocol} properly.<br /> <br /> [0]:<br /> BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]<br /> BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]<br /> BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668<br /> ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]<br /> ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]<br /> ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668<br /> ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222<br /> __netdev_start_xmit include/linux/netdevice.h:4989 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:5003 [inline]<br /> xmit_one net/core/dev.c:3547 [inline]<br /> dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563<br /> __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351<br /> dev_queue_xmit include/linux/netdevice.h:3171 [inline]<br /> packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276<br /> packet_snd net/packet/af_packet.c:3081 [inline]<br /> packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg net/socket.c:745 [inline]<br /> __sys_sendto+0x735/0xa10 net/socket.c:2191<br /> __do_sys_sendto net/socket.c:2203 [inline]<br /> __se_sys_sendto net/socket.c:2199 [inline]<br /> __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:3819 [inline]<br /> slab_alloc_node mm/slub.c:3860 [inline]<br /> __do_kmalloc_node mm/slub.c:3980 [inline]<br /> __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001<br /> kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582<br /> __<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bna: ensure the copied buf is NUL terminated<br /> <br /> Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from<br /> userspace to that buffer. Later, we use sscanf on this buffer but we don&amp;#39;t<br /> ensure that the string is terminated inside the buffer, this can lead to<br /> OOB read when using sscanf. Fix this issue by using memdup_user_nul<br /> instead of memdup_user.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix overflow in blk_ioctl_discard()<br /> <br /> There is no check for overflow of &amp;#39;start + len&amp;#39; in blk_ioctl_discard().<br /> Hung task occurs if submit an discard ioctl with the following param:<br /> start = 0x80000000000ff000, len = 0x8000000000fff000;<br /> Add the overflow validation now.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Check bloom filter map value size<br /> <br /> This patch adds a missing check to bloom filter creating, rejecting<br /> values above KMALLOC_MAX_SIZE. This brings the bloom map in line with<br /> many other map types.<br /> <br /> The lack of this protection can cause kernel crashes for value sizes<br /> that overflow int&amp;#39;s. Such a crash was caught by syzkaller. The next<br /> patch adds more guard-rails at a lower level.