Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: avoid double free of pool-&gt;stack on AQ init failure<br /> <br /> otx2_pool_aq_init() frees pool-&gt;stack when mailbox sync or retry<br /> allocation fails, but leaves the pointer unchanged. Later,<br /> otx2_sq_aura_pool_init() unwinds the partial setup through<br /> otx2_aura_pool_free(), which frees pool-&gt;stack again. The CN20K-specific<br /> cn20k_pool_aq_init() implementation has the same bug in<br /> its corresponding error path.<br /> <br /> Set pool-&gt;stack to NULL immediately after the local free so the shared<br /> cleanup path does not free the same stack again while cleaning up<br /> partially initialized pool state.<br /> <br /> The bug was first flagged by an experimental analysis tool we are<br /> developing for kernel memory-management bugs while analyzing<br /> v6.13-rc1. The tool is still under development and is not yet publicly<br /> available. Manual inspection confirms that the bug is still present in<br /> v7.1-rc3.<br /> <br /> Runtime validation was not performed because reproducing this path<br /> requires OcteonTX2/CN20K hardware.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: consume only present negotiated TTLM maps<br /> <br /> ieee80211_tid_to_link_map_size_ok() validates negotiated TTLM elements<br /> against the number of link-map entries indicated by link_map_presence.<br /> ieee80211_parse_neg_ttlm() must consume the same layout.<br /> <br /> The parser advanced its cursor for every TID, including TIDs whose<br /> presence bit is clear and therefore have no map bytes in the element.<br /> A sparse map can then make a later present TID read past the validated<br /> element.<br /> <br /> The bad bytes land in neg_ttlm-&gt;{up,down}link[tid] but are gated by<br /> valid_links before being applied to driver state, so a peer cannot<br /> turn the read into a policy change. Under KUnit + KASAN with an<br /> exact-sized element allocation the OOB read is reported as a<br /> slab-out-of-bounds; whether the same trigger fires under the<br /> production RX path depends on surrounding allocator state.<br /> <br /> Advance the cursor only when the current TID has a map present.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/time: Remove redundant preempt_disable|enable() calls from arch_irq_work_raise()<br /> <br /> A kernel panic is observed when handling machine check exceptions from<br /> real mode.<br /> <br /> BUG: Unable to handle kernel data access on read at 0xc00000006be21300<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> MSR: 8000000000001003 CR: 88222248 XER: 00000005<br /> CFAR: c00000000003ffc4 DAR: c00000006be21300 DSISR: 40000000 IRQMASK: 0<br /> NIP [c000000000029e40] arch_irq_work_raise+0x10/0x70<br /> LR [c00000000003ffc8] machine_check_queue_event+0xa8/0x150<br /> Call Trace:<br /> [c0000000179d3c70] [c00000000003ff64] machine_check_queue_event+0x44/0x150<br /> [c0000000179d3d30] [c0000000000084e0] machine_check_early_common+0x1f0/0x2c0<br /> <br /> The crash occurs because arch_irq_work_raise() calls preempt_disable()<br /> from machine check exception (MCE) handlers running in real mode. In<br /> this context, accessing the preempt_count can fault, leading to the panic.<br /> <br /> The preempt_disable()/preempt_enable() pair in arch_irq_work_raise()<br /> was originally added by commit 0fe1ac48bef0 ("powerpc/perf_event: Fix<br /> oops due to perf_event_do_pending call") to avoid races while raising<br /> irq work from exception context.<br /> <br /> Later, commit 471ba0e686cb ("irq_work: Do not raise an IPI when<br /> queueing work on the local CPU") added preemption protection in<br /> irq_work_queue() path, while commit 20b876918c06 ("irq_work: Use per<br /> cpu atomics instead of regular atomics") added equivalent<br /> protection in irq_work_queue_on() before reaching arch_irq_work_raise():<br /> <br /> irq_work_queue() / irq_work_queue_on()<br /> -&gt; preempt_disable()<br /> -&gt; __irq_work_queue_local()<br /> -&gt; irq_work_raise()<br /> -&gt; arch_irq_work_raise()<br /> <br /> As a result, callers other than mce_irq_work_raise() already execute<br /> with preemption disabled, making the additional<br /> preempt_disable()/preempt_enable() pair in arch_irq_work_raise()<br /> redundant.<br /> <br /> The arch_irq_work_raise() function executes in NMI context when called<br /> from MCE handler. Hence we will not be preempted or scheduled out since<br /> we are in NMI context with MSR[EE]=0. Therefore, it is safe to remove<br /> the preempt_disable()/preempt_enable() calls from here.<br /> <br /> Remove it to avoid accessing preempt_count from real mode context.<br /> <br /> [Maddy: Fixed the commit title]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/a6xx: Check kzalloc return in a8xx_hfi_send_perf_table<br /> <br /> Check the return value of kzalloc() to prevent a NULL pointer<br /> dereference on allocation failure.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/721342/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> device property: set fwnode-&gt;secondary to NULL in fwnode_init()<br /> <br /> If a firmware node is allocated on the stack (for instance: temporary<br /> software node whose life-time we control) or on the heap - but using a<br /> non-zeroing allocation function - and initialized using fwnode_init(),<br /> its secondary pointer will contain uninitalized memory which likely will<br /> be neither NULL nor IS_ERR() and so may end up being dereferenced (for<br /> example: in dev_to_swnode()). Set fwnode-&gt;secondary to NULL on<br /> initialization.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix potential UAF in netfs_unlock_abandoned_read_pages()<br /> <br /> netfs_unlock_abandoned_read_pages(rreq) accesses the index of the folios it<br /> is wanting to unlock and compares that to rreq-&gt;no_unlock_folio so that it<br /> doesn&amp;#39;t unlock a folio being read for netfs_perform_write() or<br /> netfs_write_begin().<br /> <br /> However, given that netfs_unlock_abandoned_read_pages() is called _after_<br /> NETFS_RREQ_IN_PROGRESS is cleared, the one folio that it&amp;#39;s not allowed to<br /> dereference is the one specified by -&gt;no_unlock_folio as ownership<br /> immediately reverts to the caller.<br /> <br /> Fix this by storing the folio pointer instead and using that rather than<br /> the index. Also fix netfs_unlock_read_folio() where the same applies.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix overrun check in netfs_extract_user_iter()<br /> <br /> Fix netfs_extract_user_iter() so that if iov_iter_extract_pages() overfills<br /> pages[], then those pages don&amp;#39;t get included in the iterator constructed at<br /> the end of the function. If there was an overfill, memory corruption has<br /> already happened.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: bla: fix report_work leak on backbone_gw purge<br /> <br /> batadv_bla_purge_backbone_gw() removes stale backbone gateway entries,<br /> but fails to properly handle their associated report_work:<br /> <br /> - If report_work is running, the purge must wait for it to finish before<br /> freeing the backbone_gw, otherwise the worker may access freed memory<br /> (e.g. bat_priv).<br /> - If report_work is pending, the purge must cancel it and release the<br /> reference held for that pending work item.<br /> <br /> The previous implementation called hlist_for_each_entry_safe() inside a<br /> spin_lock_bh() section, but cancel_work_sync() may sleep and therefore<br /> cannot be called from within a spinlock-protected region.<br /> <br /> Restructure the loop to handle one entry per spinlock critical section:<br /> acquire the lock, find the next entry to purge, remove it from the hash<br /> list, then release the lock before calling cancel_work_sync() and<br /> dropping the hash_entry reference. Repeat until no more entries require<br /> purging.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async<br /> <br /> [Why&amp;How]<br /> dc_process_dmub_aux_transfer_async() copies payload-&gt;length bytes into a<br /> 16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which<br /> is a no-op in release builds. If a caller ever passes length &gt; 16 this<br /> results in a stack buffer overflow via memcpy.<br /> <br /> Additionally, link_index is used to dereference dc-&gt;links[] without<br /> bounds checking against dc-&gt;link_count, risking an out-of-bounds access.<br /> <br /> Replace the ASSERT with a hard runtime check that returns false when<br /> payload-&gt;length exceeds the destination buffer size, and add a bounds<br /> check for link_index before it is used.<br /> <br /> (cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: ti-qspi: fix use-after-free after DMA setup failure<br /> <br /> The driver falls back to PIO mode if DMA setup fails during probe.<br /> <br /> Make sure to clear the DMA channel pointer also if buffer allocation<br /> fails to avoid passing a pointer to the released channel to the DMA<br /> engine (or trying to free the channel a second time on late probe errors<br /> or driver unbind).<br /> <br /> This issue was flagged by Sashiko when reviewing a devres allocation<br /> conversion patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: qcom: qmp-usbc: Fix out-of-bounds array access in dp swing config<br /> <br /> swing_tbl and pre_emphasis_tbl are 4x4 arrays (valid indices 0-3), but<br /> the boundary check uses "&gt; 4" instead of "&gt;= 4", allowing index 4 to<br /> cause an out-of-bounds access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> srcu: Don&amp;#39;t queue workqueue handlers to never-online CPUs<br /> <br /> While an srcu_struct structure is in the midst of switching from CPU-0<br /> to all-CPUs state, it can attempt to invoke callbacks for CPUs that<br /> have never been online. Worse yet, it can attempt in invoke callbacks<br /> for CPUs that never will be online, even including imaginary CPUs not in<br /> cpu_possible_mask. This can cause hangs on s390, which is not set up to<br /> deal with workqueue handlers being scheduled on such CPUs. This commit<br /> therefore causes Tree SRCU to refrain from queueing workqueue handlers<br /> on CPUs that have not yet (and might never) come online.<br /> <br /> Because callbacks are not invoked on CPUs that have not been<br /> online, it is an error to invoke call_srcu(), synchronize_srcu(), or<br /> synchronize_srcu_expedited() on a CPU that is not yet fully online.<br /> However, it turns out to be less code to redirect the callbacks<br /> from too-early invocations of call_srcu() than to warn about such<br /> invocations. This commit therefore also redirects callbacks queued on<br /> not-yet-fully-online CPUs to the boot CPU.