Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sunrpc: fix use-after-free in __rpc_clnt_handle_event and __rpc_clnt_remove_pipedir<br /> <br /> Normal client creation goes through rpc_setup_pipedir(), which records<br /> clnt-&gt;pipefs_sb, but the mount-event path in __rpc_clnt_handle_event()<br /> calls rpc_setup_pipedir_sb() directly and never refreshes that field.<br /> The umount path also removes the directory without clearing<br /> clnt-&gt;pipefs_sb.<br /> <br /> After a late pipefs mount or any remount, rpc_clnt_remove_pipedir()<br /> compares the current superblock against a stale pipefs_sb pointer and<br /> skips cleanup, leaving pipefs dentries whose inode private data still<br /> points at a freed rpc_clnt, leading to a potential use-after-free during<br /> subsequent rpc_info_open() or rpc_show_info() calls.<br /> <br /> Fix this by properly updating clnt-&gt;pipefs_sb upon mount events and<br /> clearing it during unmount or failure paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: fix gssx_dec_option_array error path bugs<br /> <br /> Four coupled defects in the gssx XDR option-array decoder make the<br /> error paths unsafe: a NULL deref in the caller, a refcount leak on<br /> the decoded group_info, and a latent use-after-free that the leak<br /> fix would otherwise expose.<br /> <br /> gssx_dec_option_array() sets oa-&gt;count = 1 before allocating<br /> oa-&gt;data. If that allocation fails, -ENOMEM is returned with<br /> oa-&gt;count == 1 and oa-&gt;data == NULL. All other error paths jump<br /> to free_oa: which frees oa-&gt;data and NULLs it but also leaves<br /> oa-&gt;count == 1. The caller trusts the count:<br /> <br /> gssp_accept_sec_context_upcall()<br /> gssx_dec_accept_sec_context()<br /> gssx_dec_option_array() /* fails, count=1 data=NULL */<br /> data = res.options.data[0].value /* NULL deref */<br /> <br /> Independently, free_creds: releases the partially decoded svc_cred<br /> with a bare kfree(creds). gssx_dec_linux_creds() installs a<br /> groups_alloc() result into creds-&gt;cr_group_info; that object is<br /> kvmalloc-backed and refcounted, and only put_group_info() reaches<br /> kvfree(). A plain kfree(creds) drops the wrapper and leaks the<br /> group_info allocation.<br /> <br /> The natural fix for the leak is to call free_svc_cred(creds) before<br /> kfree(creds), but free_svc_cred() invokes put_group_info() on<br /> creds-&gt;cr_group_info unconditionally when non-NULL. The existing<br /> out_free_groups: path in gssx_dec_linux_creds() already called<br /> groups_free() on that pointer without clearing it, so once<br /> free_svc_cred() is wired in, the subsequent put_group_info() would<br /> touch freed memory.<br /> <br /> Fix all four together:<br /> <br /> - Move the oa-&gt;count = 1 assignment below the oa-&gt;data allocation<br /> so it is never set when oa-&gt;data is NULL.<br /> - Reset oa-&gt;count to 0 at free_oa: so count and data stay<br /> coherent and the caller sees an empty option array.<br /> - Call free_svc_cred(creds) before kfree(creds) at free_creds:<br /> so the refcounted cr_group_info is released. free_svc_cred()<br /> either NULL-guards each field explicitly (cr_group_info has<br /> an if() check) or delegates to a helper that is NULL-safe<br /> itself (kfree for the string fields, gss_mech_put() which<br /> guards with if(gm) at gss_mech_switch.c:342), so it is safe<br /> to call on a partially decoded svc_cred where only<br /> cr_uid/cr_gid/cr_group_info have been written and everything<br /> else is zero from kzalloc.<br /> - In gssx_dec_linux_creds()&amp;#39;s out_free_groups: path, release<br /> cr_group_info with put_group_info() rather than groups_free()<br /> so the teardown matches free_svc_cred()&amp;#39;s refcount-aware path,<br /> and clear the pointer so a later free_svc_cred() on the same<br /> creds does not release it a second time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sunrpc: defer rq_argp and rq_resp free until after RCU grace period<br /> <br /> svc_rqst_free() frees rqstp-&gt;rq_argp and rqstp-&gt;rq_resp synchronously<br /> via kfree(), but defers the rqstp struct free via kfree_rcu(). After<br /> svc_exit_thread() calls list_del_rcu() and svc_rqst_free(), there is<br /> a window where RCU readers that started before list_del_rcu() can still<br /> traverse the thread list and find the rqstp. These readers (e.g.<br /> nfsd_nl_rpc_status_get_dumpit()) dereference rqstp-&gt;rq_argp, which has<br /> already been freed — a use-after-free.<br /> <br /> Fix this by moving the kfree of rq_argp and rq_resp into an explicit<br /> call_rcu() callback alongside the struct free. Resources not accessed<br /> by RCU readers (bvec, buffer pages, scratch folio, auth_data) remain<br /> synchronously freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> svcrdma: Reorder rpcrdma_rn_unregister before rdma_destroy_id<br /> <br /> svc_rdma_free() caches rdma-&gt;sc_cm_id-&gt;device before teardown,<br /> then calls rdma_destroy_id(sc_cm_id) which frees the cm_id.<br /> rpcrdma_rn_unregister() follows, but between those two calls<br /> the transport&amp;#39;s sc_rn entry is still installed in the device&amp;#39;s<br /> rd_xa. A concurrent ib_unregister_device walk can dispatch<br /> svc_rdma_xprt_done() against the now-freed sc_cm_id.<br /> <br /> Move rpcrdma_rn_unregister() before rdma_destroy_id() so the<br /> transport&amp;#39;s notification entry is removed from the xarray before<br /> the cm_id it references is destroyed.<br /> <br /> Also guard the sc_cm_id dereference with a NULL check: the<br /> following patches introduce paths that reach svc_rdma_free()<br /> with sc_cm_id == NULL (listener create failure, ADDR_CHANGE<br /> replacement failure).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/core: Make core-sched flips wait for in-flight selections<br /> <br /> Core scheduling&amp;#39;s pick_next_task() operates on all sibling rqs under one<br /> acquisition of the shared core-wide lock. A -&gt;pick_task() that releases the<br /> rq lock leaves every sibling __lock momentarily free, letting<br /> __sched_core_flip(false) complete mid-selection and rebind rq_lockp() under<br /> it. The selection resumes on the split locks, touching sibling state it no<br /> longer protects, and __schedule() finally releases a lock that was never<br /> taken while leaking the one that was.<br /> <br /> Count in-flight core-wide selections in the leader&amp;#39;s rq-&gt;core_pick_in_flight<br /> and make __sched_core_flip() wait for the count to drain. The count only<br /> changes under the shared lock, which the flip holds while sampling, so no<br /> other ordering is needed. The wait can repeat while selections overlap, but<br /> the flip backs off between samples and flips are rare cookie-lifetime<br /> events.<br /> <br /> sched_core_cpu_deactivate() moves the count to the new leader - a stale copy<br /> left behind would bias it forever if that CPU later returns as its own<br /> leader.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Make cpu_buffer::free_page a buffer_data_read_page<br /> <br /> Discarding a cached reader page after a concurrent ring buffer resize<br /> uses the new global subbuf_order for the free_pages() call. This<br /> mismatched order may crashes the kernel or leaks memory because the cached<br /> page was allocated under the old size.<br /> <br /> Save the actual free_page order alongside the page address to ensure we<br /> always refer to the correct value and do not rely on the potentially<br /> stalled cpu_buffer-&gt;subbuf_order value. The simplest is to make<br /> free_page a buffer_data_read_page which already covers exactly what we<br /> need: a page address and a page order.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Fix subbuf resize race with ring_buffer_alloc_read_page()<br /> <br /> ring_buffer_alloc_read_page() is racy with ring_buffer_subbuf_order_set,<br /> it can allocate a reader page with an outdated order. This isn&amp;#39;t a big<br /> issue, the user can still re-allocate a new reader page and try again.<br /> <br /> However, what is more problematic is if the value of subbuf_order<br /> changes in the middle of ring_buffer_alloc_read_page(). In that case,<br /> bpage-&gt;order might not match the actual allocated memory.<br /> <br /> Use bpage-&gt;order for the allocation to prevent this race.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: validate directory-index entry counts when reading metadata<br /> <br /> ocfs2_validate_dx_leaf() and ocfs2_validate_dx_root() check the ECC and<br /> signature of an indexed-directory block before it reaches higher-level<br /> callers, but neither validator bounds the ocfs2_dx_entry_list counts<br /> against the capacity of the block that holds them.<br /> <br /> ocfs2_dx_dir_search() then walks<br /> <br /> for (i = 0; i de_num_used); i++)<br /> dx_entry = &amp;entry_list-&gt;de_entries[i];<br /> <br /> over de_num_used entries with no bounds check. entry_list is either<br /> dx_leaf-&gt;dl_list (from ocfs2_read_dx_leaf) or, for an inline root,<br /> dx_root-&gt;dr_entries. A crafted on-disk image can set de_num_used (and<br /> de_count, which is the __counted_by_le() bound of de_entries) to 0xffff<br /> and make the walk read far past the end of the 4KB metadata block, giving<br /> a slab out-of-bounds read reachable from any path lookup, stat() or open()<br /> on an indexed directory once the image is mounted.<br /> <br /> Commit 775c17386a6f ("ocfs2: validate dx_root extent list fields during<br /> block read") already bounds dr_list for the non-inline dx_root, but left<br /> the inline dr_entries path and the dx_leaf dl_list unchecked. Add the<br /> same read-time validation for both entry lists: de_count must equal the<br /> capacity of the block (ocfs2_dx_entries_per_leaf()/per_root()) and<br /> de_num_used must not exceed de_count, rejecting corrupted metadata with<br /> -EFSCORRUPTED before ocfs2_dx_dir_search() can walk an out-of-range entry<br /> array.<br /> <br /> de_count is always written as exactly the block capacity when a leaf or<br /> inline root is formatted, so the equality check does not reject any valid<br /> image.<br /> <br /> Found by 0sec automated security-research tooling (https://0sec.ai).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: qcom_battmgr: fix use-after-free<br /> <br /> qcom_battmgr_pdr_notify() queues enable_work when the PMIC GLINK service<br /> comes up, and the worker recovers battmgr through container_of() to issue<br /> firmware requests. The PMIC GLINK client stays on the client list until<br /> its devres release action runs, so a PDR notification can keep queueing<br /> the work, and a pending or running worker can access battmgr after devres<br /> frees it.<br /> <br /> Make enable_work device-managed with devm_work_autocancel(), registered<br /> before the PMIC GLINK client is allocated. The devres cleanup then<br /> releases the client first, so no further notification can queue the work,<br /> and cancels the work before battmgr is freed.<br /> <br /> This issue was found by an in-house static analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/msm: Unwind probe state on registration failure<br /> <br /> msm_iommu_probe() adds its devm-managed IOMMU object to<br /> qcom_iommu_devices before adding the IOMMU sysfs device and registering<br /> it with the IOMMU core.<br /> <br /> If iommu_device_sysfs_add() fails, probe returns with the object still on<br /> qcom_iommu_devices. The driver core then releases the devm allocation,<br /> leaving a dangling list entry that later list walks may dereference.<br /> <br /> If iommu_device_register() fails, the same dangling list entry remains<br /> and the sysfs device is left registered as well.<br /> <br /> Unwind the sysfs device and global list entry in reverse setup order on<br /> the corresponding failure paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: via-sdmmc: cancel card-detect work on remove<br /> <br /> Disabling the device interrupt and freeing the IRQ prevents new card-detect<br /> work from being queued, but carddet_work already queued by the handler can<br /> still run after via_sd_remove() returns. via_sdc_card_detect() recovers the<br /> host through container_of() and dereferences its MMIO base; once remove()<br /> returns the host can be freed, so that work would touch freed memory.<br /> <br /> Cancel carddet_work after freeing the IRQ and before cancelling<br /> finish_bh_work, which the card-detect handler can also queue. carddet_work<br /> can re-enable the interrupt through via_reset_pcictrl(); mask it again<br /> afterwards.<br /> <br /> This issue was found by an in-house static analysis tool and confirmed by<br /> manual code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Fix UAF in selftest IOPF reporting<br /> <br /> IOMMUFD selftest TRIGGER_IOPF borrows an attach handle from<br /> group-&gt;pasid_array without synchronizing against PASID detach,<br /> then a concurrent iommu_report_device_fault() can dereference<br /> that borrowed handle&amp;#39;s domain pointer after the detach erases<br /> the handle and frees the backing struct iommufd_attach_handle.<br /> TRIGGER_IOPF then dereferences the freed handle, causing a UAF.<br /> <br /> Fix by adding a iopf_rwsem in mock_dev to follow the expected design<br /> of a real driver. Hold its read side across the whole<br /> iommu_report_device_fault() call, and its write side around every<br /> path that attaches, detaches, or replaces a device domain.<br /> This can block new reports and drains in-flight reports before an old<br /> attach handle or the IOPF fault parameter can be removed.<br /> Also take the write side while registering a mock device, since<br /> it can invoke the mock driver&amp;#39;s default-domain attach callback.