Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Avoid memcpy field-spanning write WARNING<br /> <br /> When the "storcli2 show" command is executed for eHBA-9600, mpi3mr driver<br /> prints this WARNING message:<br /> <br /> memcpy: detected field-spanning write (size 128) of single field "bsg_reply_buf-&gt;reply_buf" at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 (size 1)<br /> WARNING: CPU: 0 PID: 12760 at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 mpi3mr_bsg_request+0x6b12/0x7f10 [mpi3mr]<br /> <br /> The cause of the WARN is 128 bytes memcpy to the 1 byte size array "__u8<br /> replay_buf[1]" in the struct mpi3mr_bsg_in_reply_buf. The array is intended<br /> to be a flexible length array, so the WARN is a false positive.<br /> <br /> To suppress the WARN, remove the constant number &amp;#39;1&amp;#39; from the array<br /> declaration and clarify that it has flexible length. Also, adjust the<br /> memory allocation size to match the change.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: guard against invalid STA ID on removal<br /> <br /> Guard against invalid station IDs in iwl_mvm_mld_rm_sta_id as that would<br /> result in out-of-bounds array accesses. This prevents issues should the<br /> driver get into a bad state during error handling.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: read txq-&gt;read_ptr under lock<br /> <br /> If we read txq-&gt;read_ptr without lock, we can read the same<br /> value twice, then obtain the lock, and reclaim from there<br /> to two different places, but crucially reclaim the same<br /> entry twice, resulting in the WARN_ONCE() a little later.<br /> Fix that by reading txq-&gt;read_ptr under lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()<br /> <br /> lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the<br /> hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the<br /> hbalock to avoid potential deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> swiotlb: initialise restricted pool list_head when SWIOTLB_DYNAMIC=y<br /> <br /> Using restricted DMA pools (CONFIG_DMA_RESTRICTED_POOL=y) in conjunction<br /> with dynamic SWIOTLB (CONFIG_SWIOTLB_DYNAMIC=y) leads to the following<br /> crash when initialising the restricted pools at boot-time:<br /> <br /> | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008<br /> | Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> | pc : rmem_swiotlb_device_init+0xfc/0x1ec<br /> | lr : rmem_swiotlb_device_init+0xf0/0x1ec<br /> | Call trace:<br /> | rmem_swiotlb_device_init+0xfc/0x1ec<br /> | of_reserved_mem_device_init_by_idx+0x18c/0x238<br /> | of_dma_configure_id+0x31c/0x33c<br /> | platform_dma_configure+0x34/0x80<br /> <br /> faddr2line reveals that the crash is in the list validation code:<br /> <br /> include/linux/list.h:83<br /> include/linux/rculist.h:79<br /> include/linux/rculist.h:106<br /> kernel/dma/swiotlb.c:306<br /> kernel/dma/swiotlb.c:1695<br /> <br /> because add_mem_pool() is trying to list_add_rcu() to a NULL<br /> &amp;#39;mem-&gt;pools&amp;#39;.<br /> <br /> Fix the crash by initialising the &amp;#39;mem-&gt;pools&amp;#39; list_head in<br /> rmem_swiotlb_device_init() before calling add_mem_pool().