Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phylink: add lock for serializing concurrent pl-&gt;phydev writes with resolver<br /> <br /> Currently phylink_resolve() protects itself against concurrent<br /> phylink_bringup_phy() or phylink_disconnect_phy() calls which modify<br /> pl-&gt;phydev by relying on pl-&gt;state_mutex.<br /> <br /> The problem is that in phylink_resolve(), pl-&gt;state_mutex is in a lock<br /> inversion state with pl-&gt;phydev-&gt;lock. So pl-&gt;phydev-&gt;lock needs to be<br /> acquired prior to pl-&gt;state_mutex. But that requires dereferencing<br /> pl-&gt;phydev in the first place, and without pl-&gt;state_mutex, that is<br /> racy.<br /> <br /> Hence the reason for the extra lock. Currently it is redundant, but it<br /> will serve a functional purpose once mutex_lock(&amp;phy-&gt;lock) will be<br /> moved outside of the mutex_lock(&amp;pl-&gt;state_mutex) section.<br /> <br /> Another alternative considered would have been to let phylink_resolve()<br /> acquire the rtnl_mutex, which is also held when phylink_bringup_phy()<br /> and phylink_disconnect_phy() are called. But since phylink_disconnect_phy()<br /> runs under rtnl_lock(), it would deadlock with phylink_resolve() when<br /> calling flush_work(&amp;pl-&gt;resolve). Additionally, it would have been<br /> undesirable because it would have unnecessarily blocked many other call<br /> paths as well in the entire kernel, so the smaller-scoped lock was<br /> preferred.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: remove oem i2c adapter on finish<br /> <br /> Fixes a bug where unbinding of the GPU would leave the oem i2c adapter<br /> registered resulting in a null pointer dereference when applications try<br /> to access the invalid device.<br /> <br /> (cherry picked from commit 89923fb7ead4fdd37b78dd49962d9bb5892403e6)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dev_ioctl: take ops lock in hwtstamp lower paths<br /> <br /> ndo hwtstamp callbacks are expected to run under the per-device ops<br /> lock. Make the lower get/set paths consistent with the rest of ndo<br /> invocations.<br /> <br /> Kernel log:<br /> WARNING: CPU: 13 PID: 51364 at ./include/net/netdev_lock.h:70 __netdev_update_features+0x4bd/0xe60<br /> ...<br /> RIP: 0010:__netdev_update_features+0x4bd/0xe60<br /> ...<br /> Call Trace:<br /> <br /> netdev_update_features+0x1f/0x60<br /> mlx5_hwtstamp_set+0x181/0x290 [mlx5_core]<br /> mlx5e_hwtstamp_set+0x19/0x30 [mlx5_core]<br /> dev_set_hwtstamp_phylib+0x9f/0x220<br /> dev_set_hwtstamp_phylib+0x9f/0x220<br /> dev_set_hwtstamp+0x13d/0x240<br /> dev_ioctl+0x12f/0x4b0<br /> sock_ioctl+0x171/0x370<br /> __x64_sys_ioctl+0x3f7/0x900<br /> ? __sys_setsockopt+0x69/0xb0<br /> do_syscall_64+0x6f/0x2e0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> ...<br /> <br /> ....<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Note that the mlx5_hwtstamp_set and mlx5e_hwtstamp_set functions shown<br /> in the trace come from an in progress patch converting the legacy ioctl<br /> to ndo_hwtstamp_get/set and are not present in mainline.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()<br /> <br /> kasan_populate_vmalloc() and its helpers ignore the caller&amp;#39;s gfp_mask and<br /> always allocate memory using the hardcoded GFP_KERNEL flag. This makes<br /> them inconsistent with vmalloc(), which was recently extended to support<br /> GFP_NOFS and GFP_NOIO allocations.<br /> <br /> Page table allocations performed during shadow population also ignore the<br /> external gfp_mask. To preserve the intended semantics of GFP_NOFS and<br /> GFP_NOIO, wrap the apply_to_page_range() calls into the appropriate<br /> memalloc scope.<br /> <br /> xfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.<br /> <br /> There was a report here<br /> https://lkml.kernel.org/r/686ea951.050a0220.385921.0016.GAE@google.com<br /> <br /> This patch:<br /> - Extends kasan_populate_vmalloc() and helpers to take gfp_mask;<br /> - Passes gfp_mask down to alloc_pages_bulk() and __get_free_page();<br /> - Enforces GFP_NOFS/NOIO semantics with memalloc_*_save()/restore()<br /> around apply_to_page_range();<br /> - Updates vmalloc.c and percpu allocator call sites accordingly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC buffer<br /> <br /> Avoid below overlapping mappings by using a contiguous<br /> non-cacheable buffer.<br /> <br /> [ 4.077708] DMA-API: stm32_fmc2_nfc 48810000.nand-controller: cacheline tracking EEXIST,<br /> overlapping mappings aren&amp;#39;t supported<br /> [ 4.089103] WARNING: CPU: 1 PID: 44 at kernel/dma/debug.c:568 add_dma_entry+0x23c/0x300<br /> [ 4.097071] Modules linked in:<br /> [ 4.100101] CPU: 1 PID: 44 Comm: kworker/u4:2 Not tainted 6.1.82 #1<br /> [ 4.106346] Hardware name: STMicroelectronics STM32MP257F VALID1 SNOR / MB1704 (LPDDR4 Power discrete) + MB1703 + MB1708 (SNOR MB1730) (DT)<br /> [ 4.118824] Workqueue: events_unbound deferred_probe_work_func<br /> [ 4.124674] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 4.131624] pc : add_dma_entry+0x23c/0x300<br /> [ 4.135658] lr : add_dma_entry+0x23c/0x300<br /> [ 4.139792] sp : ffff800009dbb490<br /> [ 4.143016] x29: ffff800009dbb4a0 x28: 0000000004008022 x27: ffff8000098a6000<br /> [ 4.150174] x26: 0000000000000000 x25: ffff8000099e7000 x24: ffff8000099e7de8<br /> [ 4.157231] x23: 00000000ffffffff x22: 0000000000000000 x21: ffff8000098a6a20<br /> [ 4.164388] x20: ffff000080964180 x19: ffff800009819ba0 x18: 0000000000000006<br /> [ 4.171545] x17: 6361727420656e69 x16: 6c6568636163203a x15: 72656c6c6f72746e<br /> [ 4.178602] x14: 6f632d646e616e2e x13: ffff800009832f58 x12: 00000000000004ec<br /> [ 4.185759] x11: 00000000000001a4 x10: ffff80000988af58 x9 : ffff800009832f58<br /> [ 4.192916] x8 : 00000000ffffefff x7 : ffff80000988af58 x6 : 80000000fffff000<br /> [ 4.199972] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 4.207128] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000812d2c40<br /> [ 4.214185] Call trace:<br /> [ 4.216605] add_dma_entry+0x23c/0x300<br /> [ 4.220338] debug_dma_map_sg+0x198/0x350<br /> [ 4.224373] __dma_map_sg_attrs+0xa0/0x110<br /> [ 4.228411] dma_map_sg_attrs+0x10/0x2c<br /> [ 4.232247] stm32_fmc2_nfc_xfer.isra.0+0x1c8/0x3fc<br /> [ 4.237088] stm32_fmc2_nfc_seq_read_page+0xc8/0x174<br /> [ 4.242127] nand_read_oob+0x1d4/0x8e0<br /> [ 4.245861] mtd_read_oob_std+0x58/0x84<br /> [ 4.249596] mtd_read_oob+0x90/0x150<br /> [ 4.253231] mtd_read+0x68/0xac

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters()<br /> <br /> Patch series "mm/damon: avoid divide-by-zero in DAMON module&amp;#39;s parameters<br /> application".<br /> <br /> DAMON&amp;#39;s RECLAIM and LRU_SORT modules perform no validation on<br /> user-configured parameters during application, which may lead to<br /> division-by-zero errors.<br /> <br /> Avoid the divide-by-zero by adding validation checks when DAMON modules<br /> attempt to apply the parameters.<br /> <br /> <br /> This patch (of 2):<br /> <br /> During the calculation of &amp;#39;hot_thres&amp;#39; and &amp;#39;cold_thres&amp;#39;, either<br /> &amp;#39;sample_interval&amp;#39; or &amp;#39;aggr_interval&amp;#39; is used as the divisor, which may<br /> lead to division-by-zero errors. Fix it by directly returning -EINVAL<br /> when such a case occurs. Additionally, since &amp;#39;aggr_interval&amp;#39; is already<br /> required to be set no smaller than &amp;#39;sample_interval&amp;#39; in damon_set_attrs(),<br /> only the case where &amp;#39;sample_interval&amp;#39; is zero needs to be checked.

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 /> sched: Fix sched_numa_find_nth_cpu() if mask offline<br /> <br /> sched_numa_find_nth_cpu() uses a bsearch to look for the &amp;#39;closest&amp;#39;<br /> CPU in sched_domains_numa_masks and given cpus mask. However they<br /> might not intersect if all CPUs in the cpus mask are offline. bsearch<br /> will return NULL in that case, bail out instead of dereferencing a<br /> bogus pointer.<br /> <br /> The previous behaviour lead to this bug when using maxcpus=4 on an<br /> rk3399 (LLLLbb) (i.e. booting with all big CPUs offline):<br /> <br /> [ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000<br /> [ 1.423635] Mem abort info:<br /> [ 1.423889] ESR = 0x0000000096000006<br /> [ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 1.424715] SET = 0, FnV = 0<br /> [ 1.424995] EA = 0, S1PTW = 0<br /> [ 1.425279] FSC = 0x06: level 2 translation fault<br /> [ 1.425735] Data abort info:<br /> [ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000<br /> [ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000<br /> [ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000<br /> [ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP<br /> [ 1.429525] Modules linked in:<br /> [ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT<br /> [ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)<br /> [ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488<br /> [ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488<br /> [ 1.432543] sp : ffffffc084e1b960<br /> [ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0<br /> [ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000<br /> [ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378<br /> [ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff<br /> [ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7<br /> [ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372<br /> [ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860<br /> [ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000<br /> [ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68<br /> [ 1.439332] Call trace:<br /> [ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)<br /> [ 1.440016] smp_call_function_any+0xc8/0xd0<br /> [ 1.440416] armv8_pmu_init+0x58/0x27c<br /> [ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c<br /> [ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8<br /> [ 1.441603] armv8_pmu_device_probe+0x1c/0x28<br /> [ 1.442007] platform_probe+0x5c/0xac<br /> [ 1.442347] really_probe+0xbc/0x298<br /> [ 1.442683] __driver_probe_device+0x78/0x12c<br /> [ 1.443087] driver_probe_device+0xdc/0x160<br /> [ 1.443475] __driver_attach+0x94/0x19c<br /> [ 1.443833] bus_for_each_dev+0x74/0xd4<br /> [ 1.444190] driver_attach+0x24/0x30<br /> [ 1.444525] bus_add_driver+0xe4/0x208<br /> [ 1.444874] driver_register+0x60/0x128<br /> [ 1.445233] __platform_driver_register+0x24/0x30<br /> [ 1.445662] armv8_pmu_driver_init+0x28/0x4c<br /> [ 1.446059] do_one_initcall+0x44/0x25c<br /> [ 1.446416] kernel_init_freeable+0x1dc/0x3bc<br /> [ 1.446820] kernel_init+0x20/0x1d8<br /> [ 1.447151] ret_from_fork+0x10/0x20<br /> [ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)<br /> [ 1.448040] ---[ end trace 0000000000000000 ]---<br /> [ 1.448483] note: swapper/0[1] exited with preempt_count 1<br /> [ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b<br /> [ 1.449741] SMP: stopping secondary CPUs<br /> [ 1.450105] Kernel Offset: disabled<br /> [ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b<br /> [ <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ivpu: Prevent recovery work from being queued during device removal<br /> <br /> Use disable_work_sync() instead of cancel_work_sync() in ivpu_dev_fini()<br /> to ensure that no new recovery work items can be queued after device<br /> removal has started. Previously, recovery work could be scheduled even<br /> after canceling existing work, potentially leading to use-after-free<br /> bugs if recovery accessed freed resources.<br /> <br /> Rename ivpu_pm_cancel_recovery() to ivpu_pm_disable_recovery() to better<br /> reflect its new behavior.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: xilinx: axienet: Add error handling for RX metadata pointer retrieval<br /> <br /> Add proper error checking for dmaengine_desc_get_metadata_ptr() which<br /> can return an error pointer and lead to potential crashes or undefined<br /> behaviour if the pointer retrieval fails.<br /> <br /> Properly handle the error by unmapping DMA buffer, freeing the skb and<br /> returning early to prevent further processing with invalid data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTE<br /> <br /> With CONFIG_HIGHPTE on 32-bit ARM, move_pages_pte() maps PTE pages using<br /> kmap_local_page(), which requires unmapping in Last-In-First-Out order.<br /> <br /> The current code maps dst_pte first, then src_pte, but unmaps them in the<br /> same order (dst_pte, src_pte), violating the LIFO requirement. This<br /> causes the warning in kunmap_local_indexed():<br /> <br /> WARNING: CPU: 0 PID: 604 at mm/highmem.c:622 kunmap_local_indexed+0x178/0x17c<br /> addr \!= __fix_to_virt(FIX_KMAP_BEGIN + idx)<br /> <br /> Fix this by reversing the unmap order to respect LIFO ordering.<br /> <br /> This issue follows the same pattern as similar fixes:<br /> - commit eca6828403b8 ("crypto: skcipher - fix mismatch between mapping and unmapping order")<br /> - commit 8cf57c6df818 ("nilfs2: eliminate staggered calls to kunmap in nilfs_rename")<br /> <br /> Both of which addressed the same fundamental requirement that kmap_local<br /> operations must follow LIFO ordering.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: gen_estimator: fix est_timer() vs CONFIG_PREEMPT_RT=y<br /> <br /> syzbot reported a WARNING in est_timer() [1]<br /> <br /> Problem here is that with CONFIG_PREEMPT_RT=y, timer callbacks<br /> can be preempted.<br /> <br /> Adopt preempt_disable_nested()/preempt_enable_nested() to fix this.<br /> <br /> [1]<br /> WARNING: CPU: 0 PID: 16 at ./include/linux/seqlock.h:221 __seqprop_assert include/linux/seqlock.h:221 [inline]<br /> WARNING: CPU: 0 PID: 16 at ./include/linux/seqlock.h:221 est_timer+0x6dc/0x9f0 net/core/gen_estimator.c:93<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Not tainted syzkaller #0 PREEMPT_{RT,(full)}<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025<br /> RIP: 0010:__seqprop_assert include/linux/seqlock.h:221 [inline]<br /> RIP: 0010:est_timer+0x6dc/0x9f0 net/core/gen_estimator.c:93<br /> Call Trace:<br /> <br /> call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747<br /> expire_timers kernel/time/timer.c:1798 [inline]<br /> __run_timers kernel/time/timer.c:2372 [inline]<br /> __run_timer_base+0x648/0x970 kernel/time/timer.c:2384<br /> run_timer_base kernel/time/timer.c:2393 [inline]<br /> run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403<br /> handle_softirqs+0x22c/0x710 kernel/softirq.c:579<br /> __do_softirq kernel/softirq.c:613 [inline]<br /> run_ktimerd+0xcf/0x190 kernel/softirq.c:1043<br /> smpboot_thread_fn+0x53f/0xa60 kernel/smpboot.c:160<br /> kthread+0x70e/0x8a0 kernel/kthread.c:463<br /> ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br />