Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/qeth: Fix kernel panic after setting hsuid<br /> <br /> Symptom:<br /> When the hsuid attribute is set for the first time on an IQD Layer3<br /> device while the corresponding network interface is already UP,<br /> the kernel will try to execute a napi function pointer that is NULL.<br /> <br /> Example:<br /> ---------------------------------------------------------------------------<br /> [ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP<br /> [ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6<br /> nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de<br /> s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod<br /> qdio ccwgroup pkey zcrypt<br /> [ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1<br /> [ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR)<br /> [ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2)<br /> [ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3<br /> [ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000<br /> [ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80<br /> [ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8<br /> [ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68<br /> [ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal<br /> &gt;0000000000000002: 0000 illegal<br /> 0000000000000004: 0000 illegal<br /> 0000000000000006: 0000 illegal<br /> 0000000000000008: 0000 illegal<br /> 000000000000000a: 0000 illegal<br /> 000000000000000c: 0000 illegal<br /> 000000000000000e: 0000 illegal<br /> [ 2057.572800] Call Trace:<br /> [ 2057.572801] ([] 0xec639700)<br /> [ 2057.572803] [] net_rx_action+0x2ba/0x398<br /> [ 2057.572809] [] __do_softirq+0x11e/0x3a0<br /> [ 2057.572813] [] do_softirq_own_stack+0x3c/0x58<br /> [ 2057.572817] ([] do_softirq.part.1+0x56/0x60)<br /> [ 2057.572822] [] __local_bh_enable_ip+0x80/0x98<br /> [ 2057.572825] [] __dev_queue_xmit+0x2be/0xd70<br /> [ 2057.572827] [] afiucv_hs_send+0x24e/0x300 [af_iucv]<br /> [ 2057.572830] [] iucv_send_ctrl+0x102/0x138 [af_iucv]<br /> [ 2057.572833] [] iucv_sock_connect+0x37a/0x468 [af_iucv]<br /> [ 2057.572835] [] __sys_connect+0xa0/0xd8<br /> [ 2057.572839] [] sys_socketcall+0x228/0x348<br /> [ 2057.572841] [] system_call+0x2a6/0x2c8<br /> [ 2057.572843] Last Breaking-Event-Address:<br /> [ 2057.572844] [] __napi_poll+0x4c/0x1d8<br /> [ 2057.572846]<br /> [ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt<br /> -------------------------------------------------------------------------------------------<br /> <br /> Analysis:<br /> There is one napi structure per out_q: card-&gt;qdio.out_qs[i].napi<br /> The napi.poll functions are set during qeth_open().<br /> <br /> Since<br /> commit 1cfef80d4c2b ("s390/qeth: Don&amp;#39;t call dev_close/dev_open (DOWN/UP)")<br /> qeth_set_offline()/qeth_set_online() no longer call dev_close()/<br /> dev_open(). So if qeth_free_qdio_queues() cleared<br /> card-&gt;qdio.out_qs[i].napi.poll while the network interface was UP and the<br /> card was offline, they are not set again.<br /> <br /> Reproduction:<br /> chzdev -e $devno layer2=0<br /> ip link set dev $network_interface up<br /> echo 0 &gt; /sys/bus/ccw<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: fix null pointer dereference within spi_sync<br /> <br /> If spi_sync() is called with the non-empty queue and the same spi_message<br /> is then reused, the complete callback for the message remains set while<br /> the context is cleared, leading to a null pointer dereference when the<br /> callback is invoked from spi_finalize_current_message().<br /> <br /> With function inlining disabled, the call stack might look like this:<br /> <br /> _raw_spin_lock_irqsave from complete_with_flags+0x18/0x58<br /> complete_with_flags from spi_complete+0x8/0xc<br /> spi_complete from spi_finalize_current_message+0xec/0x184<br /> spi_finalize_current_message from spi_transfer_one_message+0x2a8/0x474<br /> spi_transfer_one_message from __spi_pump_transfer_message+0x104/0x230<br /> __spi_pump_transfer_message from __spi_transfer_message_noqueue+0x30/0xc4<br /> __spi_transfer_message_noqueue from __spi_sync+0x204/0x248<br /> __spi_sync from spi_sync+0x24/0x3c<br /> spi_sync from mcp251xfd_regmap_crc_read+0x124/0x28c [mcp251xfd]<br /> mcp251xfd_regmap_crc_read [mcp251xfd] from _regmap_raw_read+0xf8/0x154<br /> _regmap_raw_read from _regmap_bus_read+0x44/0x70<br /> _regmap_bus_read from _regmap_read+0x60/0xd8<br /> _regmap_read from regmap_read+0x3c/0x5c<br /> regmap_read from mcp251xfd_alloc_can_err_skb+0x1c/0x54 [mcp251xfd]<br /> mcp251xfd_alloc_can_err_skb [mcp251xfd] from mcp251xfd_irq+0x194/0xe70 [mcp251xfd]<br /> mcp251xfd_irq [mcp251xfd] from irq_thread_fn+0x1c/0x78<br /> irq_thread_fn from irq_thread+0x118/0x1f4<br /> irq_thread from kthread+0xd8/0xf4<br /> kthread from ret_from_fork+0x14/0x28<br /> <br /> Fix this by also setting message-&gt;complete to NULL when the transfer is<br /> complete.

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.