Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> qibfs: fix dentry leak<br /> <br /> simple_recursive_removal() drops the pinning references to all positives<br /> in subtree. For the cases when its argument has been kept alive by<br /> the pinning alone that&amp;#39;s exactly the right thing to do, but here<br /> the argument comes from dcache lookup, that needs to be balanced by<br /> explicit dput().<br /> <br /> Fucked-up-by: Al Viro

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/xe_migrate: Cast to output precision before multiplying operands<br /> <br /> Addressing potential overflow in result of multiplication of two lower<br /> precision (u32) operands before widening it to higher precision<br /> (u64).<br /> <br /> -v2<br /> Fix commit message and description. (Rodrigo)<br /> <br /> (cherry picked from commit 34820967ae7b45411f8f4f737c2d63b0c608e0d7)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> amd/amdkfd: sync all devices to wait all processes being evicted<br /> <br /> If there are more than one device doing reset in parallel, the first<br /> device will call kfd_suspend_all_processes() to evict all processes<br /> on all devices, this call takes time to finish. other device will<br /> start reset and recover without waiting. if the process has not been<br /> evicted before doing recover, it will be restored, then caused page<br /> fault.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phonet: fix rtm_phonet_notify() skb allocation<br /> <br /> fill_route() stores three components in the skb:<br /> <br /> - struct rtmsg<br /> - RTA_DST (u8)<br /> - RTA_OIF (u32)<br /> <br /> Therefore, rtm_phonet_notify() should use<br /> <br /> NLMSG_ALIGN(sizeof(struct rtmsg)) +<br /> nla_total_size(1) +<br /> nla_total_size(4)

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.