Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Prevent client use-after-free during delegation revoke<br /> <br /> A delegation stateid holds only a bare pointer to its owning<br /> nfs4_client and does not keep it alive. The client survives its<br /> stateids only because __destroy_client() drains cl_delegations and<br /> cl_revoked before free_client() runs.<br /> <br /> nfs4_laundromat() breaks that invariant: it unhashes an<br /> expired delegation from cl_delegations, drops deleg_lock, then<br /> revoke_delegation() relinks it onto cl_revoked under cl_lock. In that<br /> window the delegation is on neither list, so client_has_state() can<br /> report no remaining state.<br /> <br /> Every teardown path first requires cl_rpc_users to be zero, but<br /> the laundromat holds no such reference. A client whose recalled<br /> delegation has just timed out can therefore reach free_client()<br /> while revoke_delegation() is still about to dereference cl_lock,<br /> a use-after-free.<br /> <br /> Pin the client with cl_rpc_users across the revoke so teardown blocks<br /> until it completes, then reap the delegation from cl_revoked. A client<br /> already expiring reaps its own, so skip it and leave the delegation on<br /> del_recall_lru.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Prevent client use-after-free during admin state revocation<br /> <br /> A stateid holds only a bare pointer to its nfs4_client; a stateid<br /> reference does not pin it. The client survives only because<br /> __destroy_client() drains its stateids before free_client() runs.<br /> <br /> nfsd4_revoke_states() drops nn-&gt;client_lock across revoke_one_stid(),<br /> which dereferences the client to revoke a stateid and read<br /> clp-&gt;cl_minorversion. A teardown racing the dropped lock can free<br /> the client first.<br /> <br /> Pinning cl_rpc_users under client_lock blocks the DESTROY_CLIENTID and<br /> EXCHANGE_ID teardown, which refuses while cl_rpc_users is non-zero.<br /> force_expire_client() ignores it: once its wait for cl_rpc_users to<br /> reach zero has passed, a later pin goes unnoticed.<br /> <br /> Under client_lock, skip a client whose cl_time is already zero --<br /> force_expire_client() clears it there before waiting -- otherwise pin<br /> cl_rpc_users before dropping the lock. The walk then either sees the<br /> expiry and skips, or pins in time for that wait to cover the revoke.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix extent map leak in NOCOW direct I/O write<br /> <br /> btrfs_dio_iomap_begin() calls btrfs_get_extent(), which returns an<br /> extent map reference that must be dropped on all exit paths.<br /> <br /> For direct writes into a NOCOW range, btrfs_get_blocks_direct_write()<br /> keeps using that extent map and asks btrfs_create_dio_extent() to<br /> allocate the ordered extent. If that fails, for example because<br /> btrfs_alloc_ordered_extent() fails, the function returns the error<br /> without dropping the input extent map. The PREALLOC path avoided this by<br /> dropping the input extent map before replacing it with the newly created<br /> one.<br /> <br /> Check the error from btrfs_create_dio_extent() before replacing the<br /> map and drop the input extent map on failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: mcp2221: clear rxbuf after I2C/SMBus transfer completes<br /> <br /> mcp_i2c_smbus_read() stores the caller-supplied buffer pointer in<br /> mcp-&gt;rxbuf for the duration of a transfer but never clears it when the<br /> transfer finishes or times out. Once the caller frees or reuses the<br /> buffer, mcp-&gt;rxbuf becomes a dangling pointer. A delayed or spurious<br /> MCP2221_I2C_GET_DATA report can then drive mcp2221_raw_event() to<br /> memcpy device data into the freed memory, causing a write<br /> use-after-free.<br /> <br /> Route all return paths through a single exit point that clears<br /> mcp-&gt;rxbuf and mcp-&gt;rxbuf_size, so that the existing !mcp-&gt;rxbuf guard<br /> in the raw_event handler can reject any report arriving after the<br /> transfer has ended.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: universal-pidff: stop the device when force-feedback init fails<br /> <br /> universal_pidff_probe() starts the device with hid_hw_start() and then, if<br /> force-feedback initialisation fails, returns the error through a label that<br /> only does "return error". The device is left started.<br /> <br /> The HID core does not unwind on the driver&amp;#39;s behalf. __hid_device_probe()<br /> releases the devres group, closes the report and clears hdev-&gt;driver:<br /> <br /> if (ret) {<br /> devres_release_group(&amp;hdev-&gt;dev, hdev-&gt;devres_group_id);<br /> hid_close_report(hdev);<br /> hdev-&gt;driver = NULL;<br /> }<br /> <br /> The hidraw character device that hid_hw_start() registered through<br /> hid_connect() is allocated with kzalloc() and added with cdev_device_add(),<br /> so it is not devres-managed and survives that. With hdev-&gt;driver NULL,<br /> hid_device_remove() skips hid_hw_stop() as well, because it only unwinds<br /> while a driver is still attached. The registration therefore outlives the<br /> device on both paths.<br /> <br /> Opening the surviving /dev/hidrawX writes into freed memory. KASAN reports<br /> a use-after-free write from hidraw_open() -&gt; hid_hw_open() -&gt; the<br /> transport&amp;#39;s open callback, which takes a spinlock inside the freed object.<br /> A descriptor that carries a PID usage page and no input reports is enough:<br /> hidraw claims the device so hid_hw_start() succeeds, while hid-&gt;inputs<br /> stays empty so force-feedback init fails. The other failure returns in<br /> hid_pidff_init_with_quirks() - no output reports, an allocation failure,<br /> pidff_init_fields(), pidff_check_autocenter(), an unusable effect count,<br /> input_ff_create() - all reach the same label.<br /> <br /> Stop the device on that path. hid-dr.c and hid-emsff.c, which start the<br /> device with the same HID_CONNECT_DEFAULT &amp; ~HID_CONNECT_FF mask, already do<br /> this. The two earlier gotos must keep returning without hid_hw_stop(),<br /> since neither has a started device, so give the path that fails after the<br /> start its own label.<br /> <br /> Discovered by XBOW, triaged by Baul Lee

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: sony: fix UAF of ghl_poke_timer / ghl_urb at driver unbind<br /> <br /> For GHL (Guitar Hero Live) dongles, sony_probe() arms a periodic timer:<br /> ghl_magic_poke() (the timer callback) submits sc-&gt;ghl_urb, and the URB<br /> completion ghl_magic_poke_cb() re-arms the timer with mod_timer().<br /> <br /> sony_remove() drained the timer with timer_delete_sync() and then freed<br /> the URB with usb_free_urb():<br /> <br /> timer_delete_sync(&amp;sc-&gt;ghl_poke_timer);<br /> usb_free_urb(sc-&gt;ghl_urb);<br /> <br /> timer_delete_sync() does not block re-arming, and while the URB is in<br /> flight the timer is not pending, so the sync delete is a no-op. A URB<br /> completion that runs after the delete re-arms the timer, and usb_free_urb()<br /> only drops a reference -- it does not kill an in-flight URB. sc is<br /> allocated with devm_kzalloc() and freed once sony_remove() returns, so the<br /> re-armed ghl_poke_timer (embedded in sc) then fires on freed memory, a<br /> use-after-free from timer softirq. This is a disconnect/rmmod race.<br /> <br /> Poison the URB first, then shut the timer down, before freeing the URB.<br /> usb_poison_urb() kills any in-flight URB and permanently rejects further<br /> submissions, so a poke timer that is still pending cannot re-submit the<br /> URB from ghl_magic_poke() in the window before timer_shutdown_sync() runs.<br /> usb_kill_urb() would not suffice: it only cancels the in-flight URB and<br /> leaves it submittable once it returns, so the pending timer could<br /> re-submit it and put a fresh URB in flight over the freed sc.<br /> timer_shutdown_sync() then drains any last callback and blocks re-arming.<br /> The probe error path is unaffected: it is only reached before the timer<br /> is armed.<br /> <br /> Reproduced under KASAN on next-20260710 via dummy_hcd + raw-gadget<br /> emulation of the GHL PS4 dongle (VID 0x1430 / PID 0x07bb): hid-sony binds<br /> and arms the poke timer, the poke URB is held in flight, the driver is<br /> unbound (freeing sc), then the URB is released. The completion re-arms the<br /> timer on the freed sc, and the re-armed timer fires ~8 s later:<br /> <br /> BUG: KASAN: slab-use-after-free in ghl_magic_poke+0x98/0xb0<br /> Read of size 8 at addr ffff88810b02fd50 by task swapper/0/0<br /> ghl_magic_poke+0x98/0xb0<br /> call_timer_fn+0x35/0x2b0<br /> __run_timers+0x69c/0x9a0<br /> run_timer_softirq+0x173/0x2a0<br /> Allocated by task 169: sony_probe<br /> Freed by task 338: devres_release_group

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: skip sufficiently large global buffers when resizing<br /> <br /> z_erofs_gbuf_nrpages is advanced only after every global buffer has been<br /> grown. If a resize fails after some buffers were enlarged, a retry<br /> revisits those enlarged buffers.<br /> <br /> Retrying the same size then returns -ENOMEM because alloc_pages_bulk()<br /> has no pages to add and the unchanged return value is treated as a<br /> failure. Retrying an intermediate size allocates a temporary pointer<br /> array smaller than gbuf-&gt;nrpages and copies more existing pointers than<br /> the array can hold.<br /> <br /> Skip buffers that already satisfy the request. Once all remaining<br /> buffers have caught up, advancing z_erofs_gbuf_nrpages again describes<br /> the guaranteed minimum size across the pool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> acpi/apei/ghes: Use raw_spinlock_t for CXL CPER work locks<br /> <br /> The CXL CPER work registration and unregistration helpers acquire<br /> cxl_cper_work_lock and cxl_cper_prot_err_work_lock with a spinlock<br /> guard(), which leaves local interrupts enabled. The corresponding post<br /> paths (cxl_cper_post_event(), cxl_cper_post_prot_err()) execute in hard<br /> IRQ context (they are called from the GHES error notification path) and<br /> acquire the same locks with an irqsave guard().<br /> <br /> If a CPU is holding one of these locks via a spinlock guard() when a GHES<br /> interrupt arrives on the same CPU, the IRQ handler spins on the held lock<br /> waiting for it to release, while the lock holder is preempted by the IRQ.<br /> The result is a deadlock.<br /> <br /> Convert both locks from spinlock_t to raw_spinlock_t and use guard() at<br /> all call sites. On PREEMPT_RT kernels spinlock_t is backed by rt_mutex and<br /> sleeping from hard IRQ context is not permitted; raw_spinlock_t is safe in<br /> both contexts.<br /> <br /> Add WARN_ONCE to both register functions to surface double-registration<br /> bugs at runtime.<br /> <br /> Restructure both unregister functions to clear the global work pointer<br /> under the lock before calling cancel_work_sync(), closing the window<br /> where a CPER interrupt could schedule work on a pointer about to be<br /> freed. Add kfifo_reset() after cancel_work_sync() so stale entries<br /> are not replayed on next module load.<br /> <br /> Both kfifos are single-consumer: only one work_struct is registered at<br /> a time, enforced by the WARN_ONCE guard in the register functions.<br /> kfifo_reset() is safe outside the lock because cancel_work_sync() has<br /> already quiesced the consumer, and no new consumer can register until<br /> the current module exit completes and a fresh module init runs.<br /> <br /> Remove the redundant cancel_work_sync() call from cxl_ras_exit() and<br /> cxl_pci_driver_exit(). The CPER unregister functions now quiesce<br /> the work internally.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: apple-soc: Fix OPP table cleanup<br /> <br /> apple_soc_cpufreq_init() adds OPP tables from firmware, but<br /> some failure paths do not remove them. The driver also uses<br /> dev_pm_opp_remove_all_dynamic(), which is not the right cleanup<br /> helper for OPP tables loaded from firmware.<br /> <br /> Use the cpumask OPP helper after the policy CPU mask has been<br /> populated. Pair it with the matching cpumask remove helper on<br /> failure paths and in apple_soc_cpufreq_exit(). This also removes<br /> the separate dev_pm_opp_set_sharing_cpus() call, as the cpumask<br /> helper loads the DT OPP tables for all CPUs in the policy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip: orphan prefetched skbs before multicast forwarding<br /> <br /> IPv4 and IPv6 input preserve an skb-&gt;sk association installed by<br /> bpf_sk_assign() so that local delivery can use the selected socket under<br /> RCU. Both address families can also prefetch a socket in UDP early demux.<br /> In both paths (BPF and UDP early demux) a reference is not guaranteed to<br /> be held on the socket.<br /> <br /> When a multicast packet is not locally deliverable, IPv6 hands the<br /> original skb to ip6_mr_input(). IPv4&amp;#39;s ip_mr_input() similarly keeps the<br /> original skb when local delivery is not needed. Either path can put the<br /> skb on an unresolved multicast route queue or forward it after the<br /> receive-side RCU section ends.<br /> <br /> After the prefetched socket is destroyed, a later skb free invokes<br /> sock_pfree() and dereferences the stale skb-&gt;sk. Orphan the skb before<br /> each non-local multicast forwarding path. Local delivery retains the<br /> original skb; the existing skb_clone() calls provide multicast forwarding<br /> with a socket-free clone.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: rpl: fix NULL dereference of idev in ipv6_rpl_srh_rcv()<br /> <br /> ipv6_rpl_srh_rcv() dereferences idev from __in6_dev_get() without a NULL<br /> check when reading idev-&gt;cnf.rpl_seg_enabled.<br /> <br /> When the device&amp;#39;s MTU drops below IPV6_MIN_MTU, addrconf_ifdown() clears<br /> dev-&gt;ip6_ptr through RCU_INIT_POINTER(). A packet that passed the idev<br /> check in ip6_rcv_core() can then reach ipv6_rpl_srh_rcv() with<br /> dev-&gt;ip6_ptr already NULL.<br /> <br /> Reproduced by flooding the receiving interface with ping6 traffic while<br /> flapping its MTU between 1500 and 1200:<br /> <br /> BUG: KASAN: null-ptr-deref in ipv6_rpl_srh_rcv+0xb3/0x1070<br /> Read of size 4 at addr 00000000000006b4 by task ping6/394<br /> <br /> CPU: 2 UID: 0 PID: 394 Comm: ping6 Not tainted 7.2.0-rc7-micro-vm-dev-00095-g24ef02f934ee #240 PREEMPT(full)<br /> Call Trace:<br /> <br /> kasan_report+0xc6/0x100<br /> ipv6_rpl_srh_rcv+0xb3/0x1070<br /> ip6_protocol_deliver_rcu+0x759/0x9a0<br /> ip6_input_finish+0xa8/0x1b0<br /> ip6_input+0xe1/0x490<br /> ipv6_rcv+0x33d/0x460<br /> __netif_receive_skb_one_core+0xd6/0x130<br /> process_backlog+0x2cc/0xa00<br /> __napi_poll.constprop.0+0x56/0x270<br /> net_rx_action+0x327/0x730<br /> handle_softirqs+0x11e/0x630<br /> do_softirq+0xb3/0xf0<br /> <br /> <br /> Both ipv6_rpl_srh_rcv() and ipv6_srh_rcv() are called only from<br /> ipv6_rthdr_rcv(), which already has an idev lookup.<br /> <br /> Fix the NULL dereference on the RPL path by checking idev in<br /> ipv6_rthdr_rcv(), before it calls either function. The callees take idev as<br /> an argument and no longer call __in6_dev_get(), so the packet is now<br /> dropped in one place, with SKB_DROP_REASON_IPV6DISABLED on both paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation<br /> <br /> Whiteout objects are used in the upper layer of an OverlayFS to<br /> indicate that the file with this name does not exist in the unified<br /> view, even if it is present in one of the lower layer file systems.<br /> <br /> For the userspace implementations of OverlayFS (fuse-overlayfs),<br /> whiteout objects can be created from userspace as well:<br /> <br /> * mknod(2) with S_IFCHR and makedev(0, 0)<br /> * renameat2(2) with RENAME_WHITEOUT,<br /> creating the whiteout in the old place of the moved file.<br /> <br /> This commit guards whiteout creation in both of these cases with<br /> LANDLOCK_ACCESS_FS_MAKE_REG. Whiteout objects are *not* considered<br /> character devices and are not bound to a driver.<br /> <br /> LANDLOCK_ACCESS_FS_MAKE_REG describes the same permission class as a<br /> whiteout object: creating one is the only S_IFCHR creation that the VFS<br /> exempts from CAP_MKNOD, so it is as unprivileged as creating a regular<br /> file, while LANDLOCK_ACCESS_FS_MAKE_CHAR and<br /> LANDLOCK_ACCESS_FS_MAKE_BLOCK keep meaning the creation of devices that<br /> expose a kernel interface [1].<br /> <br /> For the mknod(2) case, introduce a Landlock erratum. The creation of<br /> whiteout objects through mknod(2) was previously guarded using<br /> LANDLOCK_ACCESS_FS_MAKE_CHAR, and it is now guarded using<br /> LANDLOCK_ACCESS_FS_MAKE_REG.<br /> <br /> For the renameat2(2) case, fix a bug: Before this commit, renameat2(2)<br /> with RENAME_WHITEOUT would create a directory entry even when all<br /> LANDLOCK_ACCESS_FS_MAKE_* rights were denied.<br /> <br /> This does not affect normal renames within layered OverlayFS mounts:<br /> When doing a regular rename() on a mounted fuse-overlayfs, it is the<br /> fuse-overlayfs daemon that exercises renameat2() with RENAME_WHITEOUT,<br /> and only the Landlock domain of that daemon is checked there.<br /> <br /> Depends-on: 49c9e09d9610 ("landlock: Fix handling of disconnected directories")<br /> Depends-on: fe72ce6710cb ("landlock: Add errata documentation section")<br /> [mic: Record why LANDLOCK_ACCESS_FS_MAKE_REG is the matching right, and<br /> add link(2) to the user doc]