Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iomap: avoid potential null folio-&gt;mapping deref during error reporting<br /> <br /> When a buffered read fails, iomap_finish_folio_read() reports the error<br /> with fserror_report_io(folio-&gt;mapping-&gt;host, ...). This is called after<br /> ifs-&gt;read_bytes_pending has been decremented by the bytes attempted to<br /> be read.<br /> <br /> For a folio split across multiple read completions, the folio is only<br /> guaranteed to stay locked while read_bytes_pending &gt; 0. Once<br /> iomap_finish_folio_read() decrements read_bytes_pending, another<br /> in-flight read can complete and end the read on the folio, which unlocks<br /> it. This allows truncate logic to run and detach the folio (set<br /> folio-&gt;mapping to NULL). The error reporting path then can dereference a<br /> NULL folio-&gt;mapping. As reported by Sam Sun, this is the race that can<br /> occur:<br /> <br /> CPU0: failed completion CPU1: final completion CPU2: truncate<br /> ----------------------- ---------------------- --------------<br /> read_bytes_pending -= len<br /> finished = false<br /> /* preempted before<br /> fserror_report_io() */<br /> read_bytes_pending -= len<br /> finished = true<br /> folio_end_read()<br /> truncate clears<br /> folio-&gt;mapping<br /> fserror_report_io(<br /> folio-&gt;mapping-&gt;host, ...)<br /> ^ NULL deref<br /> <br /> Fix this by reporting the error first before decrementing<br /> ifs-&gt;read_bytes_pending.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/dma: Do not try to iommu_map a 0 length region in swiotlb<br /> <br /> iommu_dma_iova_link_swiotlb() processes a mapping that is unaligned in three<br /> parts, the head, middle and trailer. If the middle is empty because there<br /> are no aligned pages it will call down to iommu_map() with a 0 size<br /> which the iommupt implementation will fail as illegal.<br /> <br /> It then tries to do an error unwind and starts from the wrong spot<br /> corrupting the mapping so the eventual destruction triggers a WARN_ON.<br /> <br /> Check for 0 length and avoid mapping and use offset not 0 as the starting<br /> point to unlink.<br /> <br /> This is frequently triggered by using some kinds of thunderbolt NVMe<br /> drives that trigger forced SWIOTLB for unaligned memory. NVMe seems to<br /> pass in oddly aligned buffers for the passthrough commands from smartctl<br /> that hit this condition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Fix NULL pointer dereference in rpmsg callback<br /> <br /> A NULL pointer dereference was observed on Hawi at boot when the DSP<br /> sends a glink message before fastrpc_rpmsg_probe() has completed<br /> initialization:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178<br /> pc : _raw_spin_lock_irqsave+0x34/0x8c<br /> lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc]<br /> ...<br /> Call trace:<br /> _raw_spin_lock_irqsave+0x34/0x8c (P)<br /> fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc]<br /> qcom_glink_native_rx+0x538/0x6a4<br /> qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem]<br /> <br /> The faulting address 0x178 corresponds to the lock variable inside<br /> struct fastrpc_channel_ctx, confirming that cctx is NULL when<br /> fastrpc_rpmsg_callback() attempts to take the spinlock.<br /> <br /> There are two issues here. First, dev_set_drvdata() is called before<br /> spin_lock_init() and idr_init(), leaving a window where the callback<br /> can retrieve a valid cctx pointer but operate on an uninitialized<br /> spinlock. Second, the rpmsg channel becomes live as soon as the driver<br /> is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata()<br /> is called at all, resulting in dev_get_drvdata() returning NULL.<br /> <br /> Fix both issues by moving all cctx initialization ahead of<br /> dev_set_drvdata() so the structure is fully initialized before it<br /> becomes visible to the callback, and add a NULL check in<br /> fastrpc_rpmsg_callback() as a guard against any remaining window.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phonet: free phonet_device after RCU grace period<br /> <br /> phonet_device_destroy() removes a phonet_device from the per-net device<br /> list with list_del_rcu(), but frees it immediately. RCU readers walking<br /> the same list can still hold a pointer to the object after it has been<br /> removed, leading to a slab-use-after-free.<br /> <br /> Use kfree_rcu(), matching the lifetime rule already used by<br /> phonet_address_del() for the same object type.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> locking/rtmutex: Skip remove_waiter() when waiter is not enqueued<br /> <br /> syzbot triggered the following splat in remove_waiter() via<br /> FUTEX_CMP_REQUEUE_PI:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f]<br /> class_raw_spinlock_constructor<br /> remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561<br /> rt_mutex_start_proxy_lock+0x103/0x120<br /> futex_requeue+0x10e4/0x20d0<br /> __x64_sys_futex+0x34f/0x4d0<br /> <br /> task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection,<br /> leaving waiter-&gt;task nil, where 3bfdc63936dd ("rtmutex: Use waiter::task instead<br /> of current in remove_waiter()") made this fatal.<br /> <br /> Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter()<br /> upon a successfully grabbing the rtmutex. 1a1fb985f2e2 ("futex: Handle early deadlock<br /> return correctly"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock()<br /> (where &amp;#39;ret&amp;#39; was only ever 0 or

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thunderbolt: Clamp XDomain response data copy to allocation size<br /> <br /> tb_xdp_properties_request() derives the per-packet copy length from<br /> the response header without checking that it fits in the previously<br /> allocated data buffer. A malicious peer can set its length field<br /> larger than the declared data_length, causing memcpy to write past<br /> the kcalloc allocation.<br /> <br /> Clamp the per-packet copy length so that the cumulative offset<br /> never exceeds data_len.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/list_lru: drain before clearing xarray entry on reparent<br /> <br /> memcg_reparent_list_lrus() clears the dying memcg&amp;#39;s xarray entry with<br /> xas_store(&amp;xas, NULL) before reparenting its per-node lists into the<br /> parent. This opens a window where a concurrent list_lru_del() arriving<br /> for the dying memcg sees xa_load() == NULL, walks to the parent in<br /> lock_list_lru_of_memcg(), takes the parent&amp;#39;s per-node lock, and calls<br /> list_del_init() on an item still physically linked on the dying memcg&amp;#39;s<br /> list.<br /> <br /> If another in-flight thread holds the dying memcg&amp;#39;s per-node lock at the<br /> same moment (another list_lru_del, or a list_lru_walk_one running an<br /> isolate callback), both threads modify -&gt;next/-&gt;prev pointers on the same<br /> physical list under different locks. Adjacent items can corrupt each<br /> other&amp;#39;s links.<br /> <br /> Fix it by reversing the order: reparent each per-node list and mark the<br /> child&amp;#39;s list lru dead and then clear the xarray entry. Any concurrent<br /> list_lru op that finds the still-set xarray entry either takes the dying<br /> memcg&amp;#39;s per-node lock (synchronizing with the drain) or sees LONG_MIN and<br /> walks to the parent, where the items now live.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmem: core: fix use-after-free bugs in error paths<br /> <br /> Fix several instances of error paths in which we call<br /> __nvmem_device_put() - which may end up freeing the underlying memory<br /> and other resources - and then keep on using the nvmem structure. Always<br /> put the reference to the nvmem device as the last step before returning<br /> the error code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: dw_mmc-rockchip: Add missing private data for very old controllers<br /> <br /> The really old controllers (rk2928, rk3066, rk3188) do not support UHS<br /> speeds at all, and thus never handled phase data.<br /> <br /> For that reason it never had a parse_dt callback and no driver private<br /> data at all.<br /> <br /> Commit ff6f0286c896 ("mmc: dw_mmc-rockchip: Add memory clock auto-gating<br /> support") makes the private data sort of mandatory, because the init<br /> function checks whether phases are configured internally or through the<br /> clock controller.<br /> <br /> This results in the old SoCs then experiencing NULL-pointer dereferences<br /> when they try to access that private-data struct.<br /> <br /> While we could have if (priv) conditionals in all places, it&amp;#39;s way less<br /> cluttery to just give the old types their private-data struct.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix the ACK parser to extract the SACK table for parsing<br /> <br /> Fix modification of the received skbuff in rxrpc_input_soft_acks() and a<br /> potential incorrect access of the buffer in a fragmented UDP packet (the<br /> packet would probably have to be deliberately pre-generated as fragmented)<br /> when AF_RXRPC tries to extract the contents of the SACK table by copying<br /> out the contents of the SACK table into a buffer before attempting to parse<br /> <br /> AF_RXRPC assumes that it can just call skb_condense() and then validly<br /> access the SACK table from skb-&gt;data and that it will be a flat buffer -<br /> but skb_condense() can silently fail to do anything under some<br /> circumstances.<br /> <br /> Note that whilst rxrpc_input_soft_acks() should be able to parse extended<br /> ACKs, the rest of AF_RXRPC doesn&amp;#39;t currently support that.<br /> <br /> Further, there&amp;#39;s then no need to call skb_condense() in rxrpc_input_ack(),<br /> so don&amp;#39;t.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thunderbolt: Reject zero-length property entries in validator<br /> <br /> tb_property_entry_valid() accepts entries with length == 0 for<br /> DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes<br /> validation but causes an underflow in the null-termination logic:<br /> <br /> property-&gt;value.text[property-&gt;length * 4 - 1] = &amp;#39;\0&amp;#39;;<br /> <br /> When property-&gt;length is 0 this writes to offset -1 relative to<br /> the allocation.<br /> <br /> Reject zero-length entries early in the validator since they have no<br /> valid representation in the XDomain property protocol.