Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/net: commit partial buffers on retry<br /> <br /> Ring provided buffers are potentially only valid within the single<br /> execution context in which they were acquired. io_uring deals with this<br /> and invalidates them on retry. But on the networking side, if<br /> MSG_WAITALL is set, or if the socket is of the streaming type and too<br /> little was processed, then it will hang on to the buffer rather than<br /> recycle or commit it. This is problematic for two reasons:<br /> <br /> 1) If someone unregisters the provided buffer ring before a later retry,<br /> then the req-&gt;buf_list will no longer be valid.<br /> <br /> 2) If multiple sockers are using the same buffer group, then multiple<br /> receives can consume the same memory. This can cause data corruption<br /> in the application, as either receive could land in the same<br /> userspace buffer.<br /> <br /> Fix this by disallowing partial retries from pinning a provided buffer<br /> across multiple executions, if ring provided buffers are used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb3: fix for slab out of bounds on mount to ksmbd<br /> <br /> With KASAN enabled, it is possible to get a slab out of bounds<br /> during mount to ksmbd due to missing check in parse_server_interfaces()<br /> (see below):<br /> <br /> BUG: KASAN: slab-out-of-bounds in<br /> parse_server_interfaces+0x14ee/0x1880 [cifs]<br /> Read of size 4 at addr ffff8881433dba98 by task mount/9827<br /> <br /> CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G<br /> OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary)<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: Dell Inc. Precision Tower 3620/0MWYPT,<br /> BIOS 2.13.1 06/14/2019<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x9f/0xf0<br /> print_report+0xd1/0x670<br /> __virt_addr_valid+0x22c/0x430<br /> ? parse_server_interfaces+0x14ee/0x1880 [cifs]<br /> ? kasan_complete_mode_report_info+0x2a/0x1f0<br /> ? parse_server_interfaces+0x14ee/0x1880 [cifs]<br /> kasan_report+0xd6/0x110<br /> parse_server_interfaces+0x14ee/0x1880 [cifs]<br /> __asan_report_load_n_noabort+0x13/0x20<br /> parse_server_interfaces+0x14ee/0x1880 [cifs]<br /> ? __pfx_parse_server_interfaces+0x10/0x10 [cifs]<br /> ? trace_hardirqs_on+0x51/0x60<br /> SMB3_request_interfaces+0x1ad/0x3f0 [cifs]<br /> ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs]<br /> ? SMB2_tcon+0x23c/0x15d0 [cifs]<br /> smb3_qfs_tcon+0x173/0x2b0 [cifs]<br /> ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]<br /> ? cifs_get_tcon+0x105d/0x2120 [cifs]<br /> ? do_raw_spin_unlock+0x5d/0x200<br /> ? cifs_get_tcon+0x105d/0x2120 [cifs]<br /> ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]<br /> cifs_mount_get_tcon+0x369/0xb90 [cifs]<br /> ? dfs_cache_find+0xe7/0x150 [cifs]<br /> dfs_mount_share+0x985/0x2970 [cifs]<br /> ? check_path.constprop.0+0x28/0x50<br /> ? save_trace+0x54/0x370<br /> ? __pfx_dfs_mount_share+0x10/0x10 [cifs]<br /> ? __lock_acquire+0xb82/0x2ba0<br /> ? __kasan_check_write+0x18/0x20<br /> cifs_mount+0xbc/0x9e0 [cifs]<br /> ? __pfx_cifs_mount+0x10/0x10 [cifs]<br /> ? do_raw_spin_unlock+0x5d/0x200<br /> ? cifs_setup_cifs_sb+0x29d/0x810 [cifs]<br /> cifs_smb3_do_mount+0x263/0x1990 [cifs]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlink: avoid infinite retry looping in netlink_unicast()<br /> <br /> netlink_attachskb() checks for the socket&amp;#39;s read memory allocation<br /> constraints. Firstly, it has:<br /> <br /> rmem sk_rcvbuf)<br /> <br /> to check if the just increased rmem value fits into the socket&amp;#39;s receive<br /> buffer. If not, it proceeds and tries to wait for the memory under:<br /> <br /> rmem + skb-&gt;truesize &gt; READ_ONCE(sk-&gt;sk_rcvbuf)<br /> <br /> The checks don&amp;#39;t cover the case when skb-&gt;truesize + sk-&gt;sk_rmem_alloc is<br /> equal to sk-&gt;sk_rcvbuf. Thus the function neither successfully accepts<br /> these conditions, nor manages to reschedule the task - and is called in<br /> retry loop for indefinite time which is caught as:<br /> <br /> rcu: INFO: rcu_sched self-detected stall on CPU<br /> rcu: 0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212<br /> (t=26000 jiffies g=230833 q=259957)<br /> NMI backtrace for cpu 0<br /> CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack lib/dump_stack.c:120<br /> nmi_cpu_backtrace.cold lib/nmi_backtrace.c:105<br /> nmi_trigger_cpumask_backtrace lib/nmi_backtrace.c:62<br /> rcu_dump_cpu_stacks kernel/rcu/tree_stall.h:335<br /> rcu_sched_clock_irq.cold kernel/rcu/tree.c:2590<br /> update_process_times kernel/time/timer.c:1953<br /> tick_sched_handle kernel/time/tick-sched.c:227<br /> tick_sched_timer kernel/time/tick-sched.c:1399<br /> __hrtimer_run_queues kernel/time/hrtimer.c:1652<br /> hrtimer_interrupt kernel/time/hrtimer.c:1717<br /> __sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1113<br /> asm_call_irq_on_stack arch/x86/entry/entry_64.S:808<br /> <br /> <br /> netlink_attachskb net/netlink/af_netlink.c:1234<br /> netlink_unicast net/netlink/af_netlink.c:1349<br /> kauditd_send_queue kernel/audit.c:776<br /> kauditd_thread kernel/audit.c:897<br /> kthread kernel/kthread.c:328<br /> ret_from_fork arch/x86/entry/entry_64.S:304<br /> <br /> Restore the original behavior of the check which commit in Fixes<br /> accidentally missed when restructuring the code.<br /> <br /> Found by Linux Verification Center (linuxtesting.org).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: asix_devices: add phy_mask for ax88772 mdio bus<br /> <br /> Without setting phy_mask for ax88772 mdio bus, current driver may create<br /> at most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f.<br /> DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phy<br /> device will bind to net phy driver. This is creating issue during system<br /> suspend/resume since phy_polling_mode() in phy_state_machine() will<br /> directly deference member of phydev-&gt;drv for non-main phy devices. Then<br /> NULL pointer dereference issue will occur. Due to only external phy or<br /> internal phy is necessary, add phy_mask for ax88772 mdio bus to workarnoud<br /> the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()<br /> <br /> Lei Lu recently reported that nfsd4_setclientid_confirm() did not check<br /> the return value from get_client_locked(). a SETCLIENTID_CONFIRM could<br /> race with a confirmed client expiring and fail to get a reference. That<br /> could later lead to a UAF.<br /> <br /> Fix this by getting a reference early in the case where there is an<br /> extant confirmed client. If that fails then treat it as if there were no<br /> confirmed client found at all.<br /> <br /> In the case where the unconfirmed client is expiring, just fail and<br /> return the result from get_client_locked().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: BPF: Fix jump offset calculation in tailcall<br /> <br /> The extra pass of bpf_int_jit_compile() skips JIT context initialization<br /> which essentially skips offset calculation leaving out_offset = -1, so<br /> the jmp_offset in emit_bpf_tail_call is calculated by<br /> <br /> "#define jmp_offset (out_offset - (cur_offset))"<br /> <br /> is a negative number, which is wrong. The final generated assembly are<br /> as follow.<br /> <br /> 54: bgeu $a2, $t1, -8 # 0x0000004c<br /> 58: addi.d $a6, $s5, -1<br /> 5c: bltz $a6, -16 # 0x0000004c<br /> 60: alsl.d $t2, $a2, $a1, 0x3<br /> 64: ld.d $t2, $t2, 264<br /> 68: beq $t2, $zero, -28 # 0x0000004c<br /> <br /> Before apply this patch, the follow test case will reveal soft lock issues.<br /> <br /> cd tools/testing/selftests/bpf/<br /> ./test_progs --allow=tailcalls/tailcall_bpf2bpf_1<br /> <br /> dmesg:<br /> watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [test_progs:25056]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ftgmac100: fix potential NULL pointer access in ftgmac100_phy_disconnect<br /> <br /> After the call to phy_disconnect() netdev-&gt;phydev is reset to NULL.<br /> So fixed_phy_unregister() would be called with a NULL pointer as argument.<br /> Therefore cache the phy_device before this call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ctnetlink: fix refcount leak on table dump<br /> <br /> There is a reference count leak in ctnetlink_dump_table():<br /> if (res ct_general); // HERE<br /> cb-&gt;args[1] = (unsigned long)ct;<br /> ...<br /> <br /> While its very unlikely, its possible that ct == last.<br /> If this happens, then the refcount of ct was already incremented.<br /> This 2nd increment is never undone.<br /> <br /> This prevents the conntrack object from being released, which in turn<br /> keeps prevents cnet-&gt;count from dropping back to 0.<br /> <br /> This will then block the netns dismantle (or conntrack rmmod) as<br /> nf_conntrack_cleanup_net_list() will wait forever.<br /> <br /> This can be reproduced by running conntrack_resize.sh selftest in a loop.<br /> It takes ~20 minutes for me on a preemptible kernel on average before<br /> I see a runaway kworker spinning in nf_conntrack_cleanup_net_list.<br /> <br /> One fix would to change this to:<br /> if (res ct_general);<br /> <br /> But this reference counting isn&amp;#39;t needed in the first place.<br /> We can just store a cookie value instead.<br /> <br /> A followup patch will do the same for ctnetlink_exp_dump_table,<br /> it looks to me as if this has the same problem and like<br /> ctnetlink_dump_table, we only need a &amp;#39;skip hint&amp;#39;, not the actual<br /> object so we can apply the same cookie strategy there as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hibmcge: fix rtnl deadlock issue<br /> <br /> Currently, the hibmcge netdev acquires the rtnl_lock in<br /> pci_error_handlers.reset_prepare() and releases it in<br /> pci_error_handlers.reset_done().<br /> <br /> However, in the PCI framework:<br /> pci_reset_bus - __pci_reset_slot - pci_slot_save_and_disable_locked -<br /> pci_dev_save_and_disable - err_handler-&gt;reset_prepare(dev);<br /> <br /> In pci_slot_save_and_disable_locked():<br /> list_for_each_entry(dev, &amp;slot-&gt;bus-&gt;devices, bus_list) {<br /> if (!dev-&gt;slot || dev-&gt;slot!= slot)<br /> continue;<br /> pci_dev_save_and_disable(dev);<br /> if (dev-&gt;subordinate)<br /> pci_bus_save_and_disable_locked(dev-&gt;subordinate);<br /> }<br /> <br /> This will iterate through all devices under the current bus and execute<br /> err_handler-&gt;reset_prepare(), causing two devices of the hibmcge driver<br /> to sequentially request the rtnl_lock, leading to a deadlock.<br /> <br /> Since the driver now executes netif_device_detach()<br /> before the reset process, it will not concurrently with<br /> other netdev APIs, so there is no need to hold the rtnl_lock now.<br /> <br /> Therefore, this patch removes the rtnl_lock during the reset process and<br /> adjusts the position of HBG_NIC_STATE_RESETTING to ensure<br /> that multiple resets are not executed concurrently.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> habanalabs: fix UAF in export_dmabuf()<br /> <br /> As soon as we&amp;#39;d inserted a file reference into descriptor table, another<br /> thread could close it. That&amp;#39;s fine for the case when all we are doing is<br /> returning that descriptor to userland (it&amp;#39;s a race, but it&amp;#39;s a userland<br /> race and there&amp;#39;s nothing the kernel can do about it). However, if we<br /> follow fd_install() with any kind of access to objects that would be<br /> destroyed on close (be it the struct file itself or anything destroyed<br /> by its -&gt;release()), we have a UAF.<br /> <br /> dma_buf_fd() is a combination of reserving a descriptor and fd_install().<br /> habanalabs export_dmabuf() calls it and then proceeds to access the<br /> objects destroyed on close. In particular, it grabs an extra reference to<br /> another struct file that will be dropped as part of -&gt;release() for ours;<br /> that "will be" is actually "might have already been".<br /> <br /> Fix that by reserving descriptor before anything else and do fd_install()<br /> only when everything had been set up. As a side benefit, we no longer<br /> have the failure exit with file already created, but reference to<br /> underlying file (as well as -&gt;dmabuf_export_cnt, etc.) not grabbed yet;<br /> unlike dma_buf_fd(), fd_install() can&amp;#39;t fail.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs: fix general protection fault in hfs_find_init()<br /> <br /> The hfs_find_init() method can trigger the crash<br /> if tree pointer is NULL:<br /> <br /> [ 45.746290][ T9787] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000008: 0000 [#1] SMP KAI<br /> [ 45.747287][ T9787] KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047]<br /> [ 45.748716][ T9787] CPU: 2 UID: 0 PID: 9787 Comm: repro Not tainted 6.16.0-rc3 #10 PREEMPT(full)<br /> [ 45.750250][ T9787] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 45.751983][ T9787] RIP: 0010:hfs_find_init+0x86/0x230<br /> [ 45.752834][ T9787] Code: c1 ea 03 80 3c 02 00 0f 85 9a 01 00 00 4c 8d 6b 40 48 c7 45 18 00 00 00 00 48 b8 00 00 00 00 00 fc<br /> [ 45.755574][ T9787] RSP: 0018:ffffc90015157668 EFLAGS: 00010202<br /> [ 45.756432][ T9787] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff819a4d09<br /> [ 45.757457][ T9787] RDX: 0000000000000008 RSI: ffffffff819acd3a RDI: ffffc900151576e8<br /> [ 45.758282][ T9787] RBP: ffffc900151576d0 R08: 0000000000000005 R09: 0000000000000000<br /> [ 45.758943][ T9787] R10: 0000000080000000 R11: 0000000000000001 R12: 0000000000000004<br /> [ 45.759619][ T9787] R13: 0000000000000040 R14: ffff88802c50814a R15: 0000000000000000<br /> [ 45.760293][ T9787] FS: 00007ffb72734540(0000) GS:ffff8880cec64000(0000) knlGS:0000000000000000<br /> [ 45.761050][ T9787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 45.761606][ T9787] CR2: 00007f9bd8225000 CR3: 000000010979a000 CR4: 00000000000006f0<br /> [ 45.762286][ T9787] Call Trace:<br /> [ 45.762570][ T9787] <br /> [ 45.762824][ T9787] hfs_ext_read_extent+0x190/0x9d0<br /> [ 45.763269][ T9787] ? submit_bio_noacct_nocheck+0x2dd/0xce0<br /> [ 45.763766][ T9787] ? __pfx_hfs_ext_read_extent+0x10/0x10<br /> [ 45.764250][ T9787] hfs_get_block+0x55f/0x830<br /> [ 45.764646][ T9787] block_read_full_folio+0x36d/0x850<br /> [ 45.765105][ T9787] ? __pfx_hfs_get_block+0x10/0x10<br /> [ 45.765541][ T9787] ? const_folio_flags+0x5b/0x100<br /> [ 45.765972][ T9787] ? __pfx_hfs_read_folio+0x10/0x10<br /> [ 45.766415][ T9787] filemap_read_folio+0xbe/0x290<br /> [ 45.766840][ T9787] ? __pfx_filemap_read_folio+0x10/0x10<br /> [ 45.767325][ T9787] ? __filemap_get_folio+0x32b/0xbf0<br /> [ 45.767780][ T9787] do_read_cache_folio+0x263/0x5c0<br /> [ 45.768223][ T9787] ? __pfx_hfs_read_folio+0x10/0x10<br /> [ 45.768666][ T9787] read_cache_page+0x5b/0x160<br /> [ 45.769070][ T9787] hfs_btree_open+0x491/0x1740<br /> [ 45.769481][ T9787] hfs_mdb_get+0x15e2/0x1fb0<br /> [ 45.769877][ T9787] ? __pfx_hfs_mdb_get+0x10/0x10<br /> [ 45.770316][ T9787] ? find_held_lock+0x2b/0x80<br /> [ 45.770731][ T9787] ? lockdep_init_map_type+0x5c/0x280<br /> [ 45.771200][ T9787] ? lockdep_init_map_type+0x5c/0x280<br /> [ 45.771674][ T9787] hfs_fill_super+0x38e/0x720<br /> [ 45.772092][ T9787] ? __pfx_hfs_fill_super+0x10/0x10<br /> [ 45.772549][ T9787] ? snprintf+0xbe/0x100<br /> [ 45.772931][ T9787] ? __pfx_snprintf+0x10/0x10<br /> [ 45.773350][ T9787] ? do_raw_spin_lock+0x129/0x2b0<br /> [ 45.773796][ T9787] ? find_held_lock+0x2b/0x80<br /> [ 45.774215][ T9787] ? set_blocksize+0x40a/0x510<br /> [ 45.774636][ T9787] ? sb_set_blocksize+0x176/0x1d0<br /> [ 45.775087][ T9787] ? setup_bdev_super+0x369/0x730<br /> [ 45.775533][ T9787] get_tree_bdev_flags+0x384/0x620<br /> [ 45.775985][ T9787] ? __pfx_hfs_fill_super+0x10/0x10<br /> [ 45.776453][ T9787] ? __pfx_get_tree_bdev_flags+0x10/0x10<br /> [ 45.776950][ T9787] ? bpf_lsm_capable+0x9/0x10<br /> [ 45.777365][ T9787] ? security_capable+0x80/0x260<br /> [ 45.777803][ T9787] vfs_get_tree+0x8e/0x340<br /> [ 45.778203][ T9787] path_mount+0x13de/0x2010<br /> [ 45.778604][ T9787] ? kmem_cache_free+0x2b0/0x4c0<br /> [ 45.779052][ T9787] ? __pfx_path_mount+0x10/0x10<br /> [ 45.779480][ T9787] ? getname_flags.part.0+0x1c5/0x550<br /> [ 45.779954][ T9787] ? putname+0x154/0x1a0<br /> [ 45.780335][ T9787] __x64_sys_mount+0x27b/0x300<br /> [ 45.780758][ T9787] ? __pfx___x64_sys_mount+0x10/0x10<br /> [ 45.781232][ T9787] <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: kcm: Fix race condition in kcm_unattach()<br /> <br /> syzbot found a race condition when kcm_unattach(psock)<br /> and kcm_release(kcm) are executed at the same time.<br /> <br /> kcm_unattach() is missing a check of the flag<br /> kcm-&gt;tx_stopped before calling queue_work().<br /> <br /> If the kcm has a reserved psock, kcm_unattach() might get executed<br /> between cancel_work_sync() and unreserve_psock() in kcm_release(),<br /> requeuing kcm-&gt;tx_work right before kcm gets freed in kcm_done().<br /> <br /> Remove kcm-&gt;tx_stopped and replace it by the less<br /> error-prone disable_work_sync().