Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: fix array_state=clear sysfs deadlock<br /> <br /> When "clear" is written to array_state, md_attr_store() breaks sysfs<br /> active protection so the array can delete itself from its own sysfs<br /> store method.<br /> <br /> However, md_attr_store() currently drops the mddev reference before<br /> calling sysfs_unbreak_active_protection(). Once do_md_stop(..., 0)<br /> has made the mddev eligible for delayed deletion, the temporary<br /> kobject reference taken by sysfs_break_active_protection() can become<br /> the last kobject reference protecting the md kobject.<br /> <br /> That allows sysfs_unbreak_active_protection() to drop the last<br /> kobject reference from the current sysfs writer context. kobject<br /> teardown then recurses into kernfs removal while the current sysfs<br /> node is still being unwound, and lockdep reports recursive locking on<br /> kn-&gt;active with kernfs_drain() in the call chain.<br /> <br /> Reproducer on an existing level:<br /> 1. Create an md0 linear array and activate it:<br /> mknod /dev/md0 b 9 0<br /> echo none &gt; /sys/block/md0/md/metadata_version<br /> echo linear &gt; /sys/block/md0/md/level<br /> echo 1 &gt; /sys/block/md0/md/raid_disks<br /> echo "$(cat /sys/class/block/sdb/dev)" &gt; /sys/block/md0/md/new_dev<br /> echo "$(($(cat /sys/class/block/sdb/size) / 2))" &gt; \<br /> /sys/block/md0/md/dev-sdb/size<br /> echo 0 &gt; /sys/block/md0/md/dev-sdb/slot<br /> echo active &gt; /sys/block/md0/md/array_state<br /> 2. Wait briefly for the array to settle, then clear it:<br /> sleep 2<br /> echo clear &gt; /sys/block/md0/md/array_state<br /> <br /> The warning looks like:<br /> <br /> WARNING: possible recursive locking detected<br /> bash/588 is trying to acquire lock:<br /> (kn-&gt;active#65) at __kernfs_remove+0x157/0x1d0<br /> but task is already holding lock:<br /> (kn-&gt;active#65) at sysfs_unbreak_active_protection+0x1f/0x40<br /> ...<br /> Call Trace:<br /> kernfs_drain<br /> __kernfs_remove<br /> kernfs_remove_by_name_ns<br /> sysfs_remove_group<br /> sysfs_remove_groups<br /> __kobject_del<br /> kobject_put<br /> md_attr_store<br /> kernfs_fop_write_iter<br /> vfs_write<br /> ksys_write<br /> <br /> Restore active protection before mddev_put() so the extra sysfs<br /> kobject reference is dropped while the mddev is still held alive. The<br /> actual md kobject deletion is then deferred until after the sysfs<br /> write path has fully returned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: reset per-IO canceled flag on each fetch<br /> <br /> If a ublk server starts recovering devices but dies before issuing fetch<br /> commands for all IOs, cancellation of the fetch commands that were<br /> successfully issued may never complete. This is because the per-IO<br /> canceled flag can remain set even after the fetch for that IO has been<br /> submitted - the per-IO canceled flags for all IOs in a queue are reset<br /> together only once all IOs for that queue have been fetched. So if a<br /> nonempty proper subset of the IOs for a queue are fetched when the ublk<br /> server dies, the IOs in that subset will never successfully be canceled,<br /> as their canceled flags remain set, and this prevents ublk_cancel_cmd<br /> from actually calling io_uring_cmd_done on the commands, despite the<br /> fact that they are outstanding.<br /> <br /> Fix this by resetting the per-IO cancel flags immediately when each IO<br /> is fetched instead of waiting for all IOs for the queue (which may never<br /> happen).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: wake raid456 reshape waiters before suspend<br /> <br /> During raid456 reshape, direct IO across the reshape position can sleep<br /> in raid5_make_request() waiting for reshape progress while still<br /> holding an active_io reference. If userspace then freezes reshape and<br /> writes md/suspend_lo or md/suspend_hi, mddev_suspend() kills active_io<br /> and waits for all in-flight IO to drain.<br /> <br /> This can deadlock: the IO needs reshape progress to continue, but the<br /> reshape thread is already frozen, so the active_io reference is never<br /> dropped and suspend never completes.<br /> <br /> raid5_prepare_suspend() already wakes wait_for_reshape for dm-raid. Do<br /> the same for normal md suspend when reshape is already interrupted, so<br /> waiting raid456 IO can abort, drop its reference, and let suspend<br /> finish.<br /> <br /> The mdadm test tests/25raid456-reshape-deadlock reproduces the hang.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix deadlock between reflink and transaction commit when using flushoncommit<br /> <br /> When using the flushoncommit mount option, we can have a deadlock between<br /> a transaction commit and a reflink operation that copied an inline extent<br /> to an offset beyond the current i_size of the destination node.<br /> <br /> The deadlock happens like this:<br /> <br /> 1) Task A clones an inline extent from inode X to an offset of inode Y<br /> that is beyond Y&amp;#39;s current i_size. This means we copied the inline<br /> extent&amp;#39;s data to a folio of inode Y that is beyond its EOF, using a<br /> call to copy_inline_to_page();<br /> <br /> 2) Task B starts a transaction commit and calls<br /> btrfs_start_delalloc_flush() to flush delalloc;<br /> <br /> 3) The delalloc flushing sees the new dirty folio of inode Y and when it<br /> attempts to flush it, it ends up at extent_writepage() and sees that<br /> the offset of the folio is beyond the i_size of inode Y, so it attempts<br /> to invalidate the folio by calling folio_invalidate(), which ends up at<br /> btrfs&amp;#39; folio invalidate callback - btrfs_invalidate_folio(). There it<br /> tries to lock the folio&amp;#39;s range in inode Y&amp;#39;s extent io tree, but it<br /> blocks since it&amp;#39;s currently locked by task A - during a reflink we lock<br /> the inodes and the source and destination ranges after flushing all<br /> delalloc and waiting for ordered extent completion - after that we<br /> don&amp;#39;t expect to have dirty folios in the ranges, the exception is if<br /> we have to copy an inline extent&amp;#39;s data (because the destination offset<br /> is not zero);<br /> <br /> 4) Task A then attempts to start a transaction to update the inode item,<br /> and then it&amp;#39;s blocked since the current transaction is in the<br /> TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the<br /> current transaction to become unblocked (its state &gt;=<br /> TRANS_STATE_UNBLOCKED).<br /> <br /> So task A is waiting for the transaction commit done by task B, and<br /> the later waiting on the extent lock of inode Y that is currently<br /> held by task A.<br /> <br /> Syzbot recently reported this with the following stack traces:<br /> <br /> INFO: task kworker/u8:7:1053 blocked for more than 143 seconds.<br /> Not tainted syzkaller #0<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:kworker/u8:7 state:D stack:23520 pid:1053 tgid:1053 ppid:2 task_flags:0x4208060 flags:0x00080000<br /> Workqueue: writeback wb_workfn (flush-btrfs-46)<br /> Call Trace:<br /> <br /> context_switch kernel/sched/core.c:5298 [inline]<br /> __schedule+0x1553/0x5240 kernel/sched/core.c:6911<br /> __schedule_loop kernel/sched/core.c:6993 [inline]<br /> schedule+0x164/0x360 kernel/sched/core.c:7008<br /> wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline]<br /> btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914<br /> btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline]<br /> btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704<br /> extent_writepage fs/btrfs/extent_io.c:1852 [inline]<br /> extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline]<br /> btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713<br /> do_writepages+0x32e/0x550 mm/page-writeback.c:2554<br /> __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750<br /> writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042<br /> wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227<br /> wb_do_writeback fs/fs-writeback.c:2374 [inline]<br /> wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414<br /> process_one_work kernel/workqueue.c:3276 [inline]<br /> process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359<br /> worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440<br /> kthread+0x388/0x470 kernel/kthread.c:436<br /> ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> INFO: task syz.4.64:6910 blocked for more than 143 seconds.<br /> Not tainted syzkaller #0<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:syz.4.64 state:D stack:22752 pid:6910 tgid:<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> amd-pstate: Fix memory leak in amd_pstate_epp_cpu_init()<br /> <br /> On failure to set the epp, the function amd_pstate_epp_cpu_init()<br /> returns with an error code without freeing the cpudata object that was<br /> allocated at the beginning of the function.<br /> <br /> Ensure that the cpudata object is freed before returning from the<br /> function.<br /> <br /> This memory leak was discovered by Claude Opus 4.6 with the aid of<br /> Chris Mason&amp;#39;s AI review-prompts<br /> (https://github.com/masoncl/review-prompts/tree/main/kernel).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: use generic driver_override infrastructure<br /> <br /> When a driver is probed through __driver_attach(), the bus&amp;#39; match()<br /> callback is called without the device lock held, thus accessing the<br /> driver_override field without a lock, which can cause a UAF.<br /> <br /> Fix this by using the driver-core driver_override infrastructure taking<br /> care of proper locking internally.<br /> <br /> Note that calling match() from __driver_attach() without the device lock<br /> held is intentional. [1]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/cio: use generic driver_override infrastructure<br /> <br /> When a driver is probed through __driver_attach(), the bus&amp;#39; match()<br /> callback is called without the device lock held, thus accessing the<br /> driver_override field without a lock, which can cause a UAF.<br /> <br /> Fix this by using the driver-core driver_override infrastructure taking<br /> care of proper locking internally.<br /> <br /> Note that calling match() from __driver_attach() without the device lock<br /> held is intentional. [1]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa: use generic driver_override infrastructure<br /> <br /> When a driver is probed through __driver_attach(), the bus&amp;#39; match()<br /> callback is called without the device lock held, thus accessing the<br /> driver_override field without a lock, which can cause a UAF.<br /> <br /> Fix this by using the driver-core driver_override infrastructure taking<br /> care of proper locking internally.<br /> <br /> Note that calling match() from __driver_attach() without the device lock<br /> held is intentional. [1]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/wmi: use generic driver_override infrastructure<br /> <br /> When a driver is probed through __driver_attach(), the bus&amp;#39; match()<br /> callback is called without the device lock held, thus accessing the<br /> driver_override field without a lock, which can cause a UAF.<br /> <br /> Fix this by using the driver-core driver_override infrastructure taking<br /> care of proper locking internally.<br /> <br /> Note that calling match() from __driver_attach() without the device lock<br /> held is intentional. [1]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/64s: Fix unmap race with PMD migration entries<br /> <br /> The following race is possible with migration swap entries or<br /> device-private THP entries. e.g. when move_pages is called on a PMD THP<br /> page, then there maybe an intermediate state, where PMD entry acts as<br /> a migration swap entry (pmd_present() is true). Then if an munmap<br /> happens at the same time, then this VM_BUG_ON() can happen in<br /> pmdp_huge_get_and_clear_full().<br /> <br /> This patch fixes that.<br /> <br /> Thread A: move_pages() syscall<br /> add_folio_for_migration()<br /> mmap_read_lock(mm)<br /> folio_isolate_lru(folio)<br /> mmap_read_unlock(mm)<br /> <br /> do_move_pages_to_node()<br /> migrate_pages()<br /> try_to_migrate_one()<br /> spin_lock(ptl)<br /> set_pmd_migration_entry()<br /> pmdp_invalidate() # PMD: _PAGE_INVALID | _PAGE_PTE | pfn<br /> set_pmd_at() # PMD: migration swap entry (pmd_present=0)<br /> spin_unlock(ptl)<br /> [page copy phase] # <br /> <br /> Thread B: munmap()<br /> mmap_write_downgrade(mm)<br /> unmap_vmas() -&gt; zap_pmd_range()<br /> zap_huge_pmd()<br /> __pmd_trans_huge_lock()<br /> pmd_is_huge(): # !pmd_present &amp;&amp; !pmd_none -&gt; TRUE (swap entry)<br /> pmd_lock() -&gt; # spin_lock(ptl), waits for Thread A to release ptl<br /> pmdp_huge_get_and_clear_full()<br /> VM_BUG_ON(!pmd_present(*pmdp)) # HITS!<br /> <br /> [ 287.738700][ T1867] ------------[ cut here ]------------<br /> [ 287.743843][ T1867] kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:187!<br /> cpu 0x0: Vector: 700 (Program Check) at [c00000044037f4f0]<br /> pc: c000000000094ca4: pmdp_huge_get_and_clear_full+0x6c/0x23c<br /> lr: c000000000645dec: zap_huge_pmd+0xb0/0x868<br /> sp: c00000044037f790<br /> msr: 800000000282b033<br /> current = 0xc0000004032c1a00<br /> paca = 0xc000000004fe0000 irqmask: 0x03 irq_happened: 0x09<br /> pid = 1867, comm = a.out<br /> kernel BUG at :187!<br /> Linux version 6.19.0-12136-g14360d4f917c-dirty (powerpc64le-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #27 SMP PREEMPT Sun Feb 22 10:38:56 IST 2026<br /> enter ? for help<br /> [link register ] c000000000645dec zap_huge_pmd+0xb0/0x868<br /> [c00000044037f790] c00000044037f7d0 (unreliable)<br /> [c00000044037f7d0] c000000000645dcc zap_huge_pmd+0x90/0x868<br /> [c00000044037f840] c0000000005724cc unmap_page_range+0x176c/0x1f40<br /> [c00000044037fa00] c000000000572ea0 unmap_vmas+0xb0/0x1d8<br /> [c00000044037fa90] c0000000005af254 unmap_region+0xb4/0x128<br /> [c00000044037fb50] c0000000005af400 vms_complete_munmap_vmas+0x138/0x310<br /> [c00000044037fbe0] c0000000005b0f1c do_vmi_align_munmap+0x1ec/0x238<br /> [c00000044037fd30] c0000000005b3688 __vm_munmap+0x170/0x1f8<br /> [c00000044037fdf0] c000000000587f74 sys_munmap+0x2c/0x40<br /> [c00000044037fe10] c000000000032668 system_call_exception+0x128/0x350<br /> [c00000044037fe50] c00000000000d05c system_call_vectored_common+0x15c/0x2ec<br /> ---- Exception: 3000 (System Call Vectored) at 0000000010064a2c<br /> SP (7fff9b1ee9c0) is in userspace<br /> 0:mon&gt; zh<br /> <br /> commit a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages"),<br /> enabled migration for device-private PMD entries. Hence this is one<br /> other path where this warning could get trigger from.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: arch/powerpc/mm/book3s64/hash_pgtable.c:199 at hash__pmd_hugepage_update+0x48/0x284, CPU#3: hmm-tests/1905<br /> Modules linked in: test_hmm<br /> CPU: 3 UID: 0 PID: 1905 Comm: hmm-tests Tainted: G B W L N 7.0.0-rc1-01438-g7e2f0ee7581c #21 PREEMPT<br /> Tainted: [B]=BAD_PAGE, [W]=WARN, [L]=SOFTLOCKUP, [N]=TEST<br /> Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) 0x801200 0xf000006 of:SLOF,git-ee03ae pSeries<br /> NIP [c000000000096b70] hash__pmd_hugepage_update+0x48/0x284<br /> LR [c000000000096e7c] hash__pmdp_huge_get_and_clear+0xd0/0xd4<br /> Call Trace:<br /> [c000000604707670] [c000000004e102b8] 0xc000000004e102b8 (unreliable)<br /> [c000000604707700] [c00000000064ec3c] set_pmd_migration_entry+0x414/0x498<br /> [c000000604707760] [c00000000063e5a4] migrate_vma_col<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pgtable-frag: Fix bad page state in pte_frag_destroy<br /> <br /> powerpc uses pt_frag_refcount as a reference counter for tracking it&amp;#39;s<br /> pte and pmd page table fragments. For PTE table, in case of Hash with<br /> 64K pagesize, we have 16 fragments of 4K size in one 64K page.<br /> <br /> Patch series [1] "mm: free retracted page table by RCU"<br /> added pte_free_defer() to defer the freeing of PTE tables when<br /> retract_page_tables() is called for madvise MADV_COLLAPSE on shmem<br /> range.<br /> [1]: https://lore.kernel.org/all/7cd843a9-aa80-14f-5eb2-33427363c20@google.com/<br /> <br /> pte_free_defer() sets the active flag on the corresponding fragment&amp;#39;s<br /> folio &amp; calls pte_fragment_free(), which reduces the pt_frag_refcount.<br /> When pt_frag_refcount reaches 0 (no active fragment using the folio), it<br /> checks if the folio active flag is set, if set, it calls call_rcu to<br /> free the folio, it the active flag is unset then it calls pte_free_now().<br /> <br /> Now, this can lead to following problem in a corner case...<br /> <br /> [ 265.351553][ T183] BUG: Bad page state in process a.out pfn:20d62<br /> [ 265.353555][ T183] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x20d62<br /> [ 265.355457][ T183] flags: 0x3ffff800000100(active|node=0|zone=0|lastcpupid=0x7ffff)<br /> [ 265.358719][ T183] raw: 003ffff800000100 0000000000000000 5deadbeef0000122 0000000000000000<br /> [ 265.360177][ T183] raw: 0000000000000000 c0000000119caf58 00000000ffffffff 0000000000000000<br /> [ 265.361438][ T183] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set<br /> [ 265.362572][ T183] Modules linked in:<br /> [ 265.364622][ T183] CPU: 0 UID: 0 PID: 183 Comm: a.out Not tainted 6.18.0-rc3-00141-g1ddeaaace7ff-dirty #53 VOLUNTARY<br /> [ 265.364785][ T183] Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) 0x801200 0xf000006 of:SLOF,git-ee03ae pSeries<br /> [ 265.364908][ T183] Call Trace:<br /> [ 265.364955][ T183] [c000000011e6f7c0] [c000000001cfaa18] dump_stack_lvl+0x130/0x148 (unreliable)<br /> [ 265.365202][ T183] [c000000011e6f7f0] [c000000000794758] bad_page+0xb4/0x1c8<br /> [ 265.365384][ T183] [c000000011e6f890] [c00000000079c020] __free_frozen_pages+0x838/0xd08<br /> [ 265.365554][ T183] [c000000011e6f980] [c0000000000a70ac] pte_frag_destroy+0x298/0x310<br /> [ 265.365729][ T183] [c000000011e6fa30] [c0000000000aa764] arch_exit_mmap+0x34/0x218<br /> [ 265.365912][ T183] [c000000011e6fa80] [c000000000751698] exit_mmap+0xb8/0x820<br /> [ 265.366080][ T183] [c000000011e6fc30] [c0000000001b1258] __mmput+0x98/0x300<br /> [ 265.366244][ T183] [c000000011e6fc80] [c0000000001c81f8] do_exit+0x470/0x1508<br /> [ 265.366421][ T183] [c000000011e6fd70] [c0000000001c95e4] do_group_exit+0x88/0x148<br /> [ 265.366602][ T183] [c000000011e6fdc0] [c0000000001c96ec] pid_child_should_wake+0x0/0x178<br /> [ 265.366780][ T183] [c000000011e6fdf0] [c00000000003a270] system_call_exception+0x1b0/0x4e0<br /> [ 265.366958][ T183] [c000000011e6fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec<br /> <br /> The bad page state error occurs when such a folio gets freed (with<br /> active flag set), from do_exit() path in parallel.<br /> <br /> ... this can happen when the pte fragment was allocated from this folio,<br /> but when all the fragments get freed, the pte_frag_refcount still had some<br /> unused fragments. Now, if this process exits, with such folio as it&amp;#39;s cached<br /> pte_frag in mm-&gt;context, then during pte_frag_destroy(), we simply call<br /> pagetable_dtor() and pagetable_free(), meaning it doesn&amp;#39;t clear the<br /> active flag. This, can lead to the above bug. Since we are anyway in<br /> do_exit() path, then if the refcount is 0, then I guess it should be<br /> ok to simply clear the folio active flag before calling pagetable_dtor()<br /> &amp; pagetable_free().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/bpf: Zero-extend bpf prog return values and kfunc arguments<br /> <br /> s390x ABI requires callers to zero-extend unsigned arguments and<br /> sign-extend signed arguments, and callees to zero-extend unsigned<br /> return values and sign-extend signed return values.<br /> <br /> s390 BPF JIT currently implements only sign extension. Fix this<br /> omission and implement zero extension too.