Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: elan_i2c - validate firmware size before use<br /> <br /> Ensure that the firmware file is large enough to contain the expected<br /> number of pages and the signature (which resides at the end of the<br /> firmware blob) before accessing them to prevent potential out-of-bounds<br /> reads.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: fix double free in rvu_rep_rsrc_init()<br /> <br /> rvu_rep_rsrc_init() allocates queue memory before calling<br /> otx2_init_hw_resources(). When hardware resource setup fails,<br /> otx2_init_hw_resources() already unwinds the partially initialized<br /> SQ, CQ, and aura state before returning an error. The representor<br /> error path then calls otx2_free_hw_resources() again and can free<br /> the same resources a second time.<br /> <br /> Fix this by splitting the cleanup labels so that a failure from<br /> otx2_init_hw_resources() only releases queue memory. Keep the<br /> otx2_free_hw_resources() call for failures that happen after<br /> hardware resource initialization completed successfully.<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<br /> present in v7.1-rc3.<br /> <br /> Runtime validation was not performed because reproducing this path<br /> requires OcteonTX2 representor hardware.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: CGX: add bounds check to cgx_speed_mbps index<br /> <br /> cgx_speed_mbps has 13 elements but RESP_LINKSTAT_SPEED can yield values<br /> 0-15. If it returns a value &gt;= 13, this causes an out-of-bounds array<br /> access. Add a bounds check and default to speed 0 if the index is out of<br /> range.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Avoid UAF in scx_root_enable_workfn() init failure path<br /> <br /> In scx_root_enable_workfn(), put_task_struct(p) is called before scx_error()<br /> dereferences p-&gt;comm and p-&gt;pid. If the iterator&amp;#39;s reference is the last<br /> drop, the task is freed synchronously and the deref becomes a UAF.<br /> <br /> Move put_task_struct() past scx_error().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: driver: Check ACPI_COMPANION() against NULL during probe<br /> <br /> Since every platform driver can be forced to match a device that doesn&amp;#39;t<br /> match its list of device IDs because of device_match_driver_override(),<br /> platform drivers that rely on the existence of a device&amp;#39;s ACPI companion<br /> object should verify its presence.<br /> <br /> Accordingly, add requisite ACPI_COMPANION() or ACPI_HANDLE() checks<br /> against NULL to 13 platform drivers handling core ACPI devices.<br /> <br /> Also change the value returned by the ACPI thermal zone driver when<br /> the device&amp;#39;s ACPI companion is not present to -ENODEV for consistency<br /> with the other drivers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethtool: phy: avoid NULL deref when PHY driver is unbound<br /> <br /> phydev-&gt;drv can become NULL while the phy_device is still attached to<br /> its net_device, namely after the PHY driver is unbound via sysfs:<br /> <br /> echo &gt; /sys/bus/mdio_bus/drivers//unbind<br /> <br /> phy_remove() clears phydev-&gt;drv but doesn&amp;#39;t call phy_detach(), so the<br /> phy_device stays in the link topology xarray and ethnl_req_get_phydev()<br /> still hands it back. ETHTOOL_MSG_PHY_GET then oopses on:<br /> <br /> rep_data-&gt;drvname = kstrdup(phydev-&gt;drv-&gt;name, GFP_KERNEL);<br /> <br /> drvname is already treated as optional by phy_reply_size(),<br /> phy_fill_reply() and phy_cleanup_data(), so just skip the allocation<br /> when there is no driver bound.

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 /> 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.