Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before using<br /> <br /> Running IDXD workloads in a container with the /dev directory mounted can<br /> trigger a call trace or even a kernel panic when the parent process of the<br /> container is terminated.<br /> <br /> This issue occurs because, under certain configurations, Docker does not<br /> properly propagate the mount replica back to the original mount point.<br /> <br /> In this case, when the user driver detaches, the WQ is destroyed but it<br /> still calls destroy_workqueue() attempting to completes all pending work.<br /> It&amp;#39;s necessary to check wq-&gt;wq and skip the drain if it no longer exists.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix failure to rebuild free space tree using multiple transactions<br /> <br /> If we are rebuilding a free space tree, while modifying the free space<br /> tree we may need to allocate a new metadata block group.<br /> If we end up using multiple transactions for the rebuild, when we call<br /> btrfs_end_transaction() we enter btrfs_create_pending_block_groups()<br /> which calls add_block_group_free_space() to add items to the free space<br /> tree for the block group.<br /> <br /> Then later during the free space tree rebuild, at<br /> btrfs_rebuild_free_space_tree(), we may find such new block groups<br /> and call populate_free_space_tree() for them, which fails with -EEXIST<br /> because there are already items in the free space tree. Then we abort the<br /> transaction with -EEXIST at btrfs_rebuild_free_space_tree().<br /> Notice that we say "may find" the new block groups because a new block<br /> group may be inserted in the block groups rbtree, which is being iterated<br /> by the rebuild process, before or after the current node where the rebuild<br /> process is currently at.<br /> <br /> Syzbot recently reported such case which produces a trace like the<br /> following:<br /> <br /> ------------[ cut here ]------------<br /> BTRFS: Transaction aborted (error -17)<br /> WARNING: CPU: 1 PID: 7626 at fs/btrfs/free-space-tree.c:1341 btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 7626 Comm: syz.2.25 Not tainted 6.15.0-rc7-syzkaller-00085-gd7fa1af5b33e-dirty #0 PREEMPT<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341<br /> lr : btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341<br /> sp : ffff80009c4f7740<br /> x29: ffff80009c4f77b0 x28: ffff0000d4c3f400 x27: 0000000000000000<br /> x26: dfff800000000000 x25: ffff70001389eee8 x24: 0000000000000003<br /> x23: 1fffe000182b6e7b x22: 0000000000000000 x21: ffff0000c15b73d8<br /> x20: 00000000ffffffef x19: ffff0000c15b7378 x18: 1fffe0003386f276<br /> x17: ffff80008f31e000 x16: ffff80008adbe98c x15: 0000000000000001<br /> x14: 1fffe0001b281550 x13: 0000000000000000 x12: 0000000000000000<br /> x11: ffff60001b281551 x10: 0000000000000003 x9 : 1c8922000a902c00<br /> x8 : 1c8922000a902c00 x7 : ffff800080485878 x6 : 0000000000000000<br /> x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff80008047843c<br /> x2 : 0000000000000001 x1 : ffff80008b3ebc40 x0 : 0000000000000001<br /> Call trace:<br /> btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341 (P)<br /> btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074<br /> btrfs_remount_rw fs/btrfs/super.c:1319 [inline]<br /> btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543<br /> reconfigure_super+0x1d4/0x6f0 fs/super.c:1083<br /> do_remount fs/namespace.c:3365 [inline]<br /> path_mount+0xb34/0xde0 fs/namespace.c:4200<br /> do_mount fs/namespace.c:4221 [inline]<br /> __do_sys_mount fs/namespace.c:4432 [inline]<br /> __se_sys_mount fs/namespace.c:4409 [inline]<br /> __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767<br /> el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786<br /> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600<br /> irq event stamp: 330<br /> hardirqs last enabled at (329): [] raw_spin_rq_unlock_irq kernel/sched/sched.h:1525 [inline]<br /> hardirqs last enabled at (329): [] finish_lock_switch+0xb0/0x1c0 kernel/sched/core.c:5130<br /> hardirqs last disabled at (330): [] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:511<br /> softirqs last enabled at (10): [] local_bh_enable+0<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix a race between renames and directory logging<br /> <br /> We have a race between a rename and directory inode logging that if it<br /> happens and we crash/power fail before the rename completes, the next time<br /> the filesystem is mounted, the log replay code will end up deleting the<br /> file that was being renamed.<br /> <br /> This is best explained following a step by step analysis of an interleaving<br /> of steps that lead into this situation.<br /> <br /> Consider the initial conditions:<br /> <br /> 1) We are at transaction N;<br /> <br /> 2) We have directories A and B created in a past transaction (

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: KVM: Check validity of "num_cpu" from user space<br /> <br /> The maximum supported cpu number is EIOINTC_ROUTE_MAX_VCPUS about<br /> irqchip EIOINTC, here add validation about cpu number to avoid array<br /> pointer overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: KVM: Avoid overflow with array index<br /> <br /> The variable index is modified and reused as array index when modify<br /> register EIOINTC_ENABLE. There will be array index overflow problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/gpu: Fix crash when throttling GPU immediately during boot<br /> <br /> There is a small chance that the GPU is already hot during boot. In that<br /> case, the call to of_devfreq_cooling_register() will immediately try to<br /> apply devfreq cooling, as seen in the following crash:<br /> <br /> Unable to handle kernel paging request at virtual address 0000000000014110<br /> pc : a6xx_gpu_busy+0x1c/0x58 [msm]<br /> lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm]<br /> Call trace:<br /> a6xx_gpu_busy+0x1c/0x58 [msm] (P)<br /> devfreq_simple_ondemand_func+0x3c/0x150<br /> devfreq_update_target+0x44/0xd8<br /> qos_max_notifier_call+0x30/0x84<br /> blocking_notifier_call_chain+0x6c/0xa0<br /> pm_qos_update_target+0xd0/0x110<br /> freq_qos_apply+0x3c/0x74<br /> apply_constraint+0x88/0x148<br /> __dev_pm_qos_update_request+0x7c/0xcc<br /> dev_pm_qos_update_request+0x38/0x5c<br /> devfreq_cooling_set_cur_state+0x98/0xf0<br /> __thermal_cdev_update+0x64/0xb4<br /> thermal_cdev_update+0x4c/0x58<br /> step_wise_manage+0x1f0/0x318<br /> __thermal_zone_device_update+0x278/0x424<br /> __thermal_cooling_device_register+0x2bc/0x308<br /> thermal_of_cooling_device_register+0x10/0x1c<br /> of_devfreq_cooling_register_power+0x240/0x2bc<br /> of_devfreq_cooling_register+0x14/0x20<br /> msm_devfreq_init+0xc4/0x1a0 [msm]<br /> msm_gpu_init+0x304/0x574 [msm]<br /> adreno_gpu_init+0x1c4/0x2e0 [msm]<br /> a6xx_gpu_init+0x5c8/0x9c8 [msm]<br /> adreno_bind+0x2a8/0x33c [msm]<br /> ...<br /> <br /> At this point we haven&amp;#39;t initialized the GMU at all yet, so we cannot read<br /> the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before<br /> in commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in<br /> 6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), but<br /> unlike msm_devfreq_suspend(), it doesn&amp;#39;t set the df-&gt;suspended flag<br /> accordingly. This means the df-&gt;suspended flag does not match the actual<br /> devfreq state after initialization and msm_devfreq_get_dev_status() will<br /> end up accessing GMU registers, causing the crash.<br /> <br /> Fix this by setting df-&gt;suspended correctly during initialization.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/650772/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Process deferred GGTT node removals on device unwind<br /> <br /> While we are indirectly draining our dedicated workqueue ggtt-&gt;wq<br /> that we use to complete asynchronous removal of some GGTT nodes,<br /> this happends as part of the managed-drm unwinding (ggtt_fini_early),<br /> which could be later then manage-device unwinding, where we could<br /> already unmap our MMIO/GMS mapping (mmio_fini).<br /> <br /> This was recently observed during unsuccessful VF initialization:<br /> <br /> [ ] xe 0000:00:02.1: probe with driver xe failed with error -62<br /> [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747340 __xe_bo_unpin_map_no_vm (16 bytes)<br /> [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747540 __xe_bo_unpin_map_no_vm (16 bytes)<br /> [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747240 __xe_bo_unpin_map_no_vm (16 bytes)<br /> [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747040 tiles_fini (16 bytes)<br /> [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746840 mmio_fini (16 bytes)<br /> [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747f40 xe_bo_pinned_fini (16 bytes)<br /> [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746b40 devm_drm_dev_init_release (16 bytes)<br /> [ ] xe 0000:00:02.1: [drm:drm_managed_release] drmres release begin<br /> [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef81640 __fini_relay (8 bytes)<br /> [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80d40 guc_ct_fini (8 bytes)<br /> [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80040 __drmm_mutex_release (8 bytes)<br /> [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80140 ggtt_fini_early (8 bytes)<br /> <br /> and this was leading to:<br /> <br /> [ ] BUG: unable to handle page fault for address: ffffc900058162a0<br /> [ ] #PF: supervisor write access in kernel mode<br /> [ ] #PF: error_code(0x0002) - not-present page<br /> [ ] Oops: Oops: 0002 [#1] SMP NOPTI<br /> [ ] Tainted: [W]=WARN<br /> [ ] Workqueue: xe-ggtt-wq ggtt_node_remove_work_func [xe]<br /> [ ] RIP: 0010:xe_ggtt_set_pte+0x6d/0x350 [xe]<br /> [ ] Call Trace:<br /> [ ] <br /> [ ] xe_ggtt_clear+0xb0/0x270 [xe]<br /> [ ] ggtt_node_remove+0xbb/0x120 [xe]<br /> [ ] ggtt_node_remove_work_func+0x30/0x50 [xe]<br /> [ ] process_one_work+0x22b/0x6f0<br /> [ ] worker_thread+0x1e8/0x3d<br /> <br /> Add managed-device action that will explicitly drain the workqueue<br /> with all pending node removals prior to releasing MMIO/GSM mapping.<br /> <br /> (cherry picked from commit 89d2835c3680ab1938e22ad81b1c9f8c686bd391)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/guc: Explicitly exit CT safe mode on unwind<br /> <br /> During driver probe we might be briefly using CT safe mode, which<br /> is based on a delayed work, but usually we are able to stop this<br /> once we have IRQ fully operational. However, if we abort the probe<br /> quite early then during unwind we might try to destroy the workqueue<br /> while there is still a pending delayed work that attempts to restart<br /> itself which triggers a WARN.<br /> <br /> This was recently observed during unsuccessful VF initialization:<br /> <br /> [ ] xe 0000:00:02.1: probe with driver xe failed with error -62<br /> [ ] ------------[ cut here ]------------<br /> [ ] workqueue: cannot queue safe_mode_worker_func [xe] on wq xe-g2h-wq<br /> [ ] WARNING: CPU: 9 PID: 0 at kernel/workqueue.c:2257 __queue_work+0x287/0x710<br /> [ ] RIP: 0010:__queue_work+0x287/0x710<br /> [ ] Call Trace:<br /> [ ] delayed_work_timer_fn+0x19/0x30<br /> [ ] call_timer_fn+0xa1/0x2a0<br /> <br /> Exit the CT safe mode on unwind to avoid that warning.<br /> <br /> (cherry picked from commit 2ddbb73ec20b98e70a5200cb85deade22ccea2ec)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix race between async reclaim worker and close_ctree()<br /> <br /> Syzbot reported an assertion failure due to an attempt to add a delayed<br /> iput after we have set BTRFS_FS_STATE_NO_DELAYED_IPUT in the fs_info<br /> state:<br /> <br /> WARNING: CPU: 0 PID: 65 at fs/btrfs/inode.c:3420 btrfs_add_delayed_iput+0x2f8/0x370 fs/btrfs/inode.c:3420<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 65 Comm: kworker/u8:4 Not tainted 6.15.0-next-20250530-syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> Workqueue: btrfs-endio-write btrfs_work_helper<br /> RIP: 0010:btrfs_add_delayed_iput+0x2f8/0x370 fs/btrfs/inode.c:3420<br /> Code: 4e ad 5d (...)<br /> RSP: 0018:ffffc9000213f780 EFLAGS: 00010293<br /> RAX: ffffffff83c635b7 RBX: ffff888058920000 RCX: ffff88801c769e00<br /> RDX: 0000000000000000 RSI: 0000000000000100 RDI: 0000000000000000<br /> RBP: 0000000000000001 R08: ffff888058921b67 R09: 1ffff1100b12436c<br /> R10: dffffc0000000000 R11: ffffed100b12436d R12: 0000000000000001<br /> R13: dffffc0000000000 R14: ffff88807d748000 R15: 0000000000000100<br /> FS: 0000000000000000(0000) GS:ffff888125c53000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00002000000bd038 CR3: 000000006a142000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> btrfs_put_ordered_extent+0x19f/0x470 fs/btrfs/ordered-data.c:635<br /> btrfs_finish_one_ordered+0x11d8/0x1b10 fs/btrfs/inode.c:3312<br /> btrfs_work_helper+0x399/0xc20 fs/btrfs/async-thread.c:312<br /> process_one_work kernel/workqueue.c:3238 [inline]<br /> process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321<br /> worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402<br /> kthread+0x70e/0x8a0 kernel/kthread.c:464<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 /> <br /> <br /> This can happen due to a race with the async reclaim worker like this:<br /> <br /> 1) The async metadata reclaim worker enters shrink_delalloc(), which calls<br /> btrfs_start_delalloc_roots() with an nr_pages argument that has a value<br /> less than LONG_MAX, and that in turn enters start_delalloc_inodes(),<br /> which sets the local variable &amp;#39;full_flush&amp;#39; to false because<br /> wbc-&gt;nr_to_write is less than LONG_MAX;<br /> <br /> 2) There it finds inode X in a root&amp;#39;s delalloc list, grabs a reference for<br /> inode X (with igrab()), and triggers writeback for it with<br /> filemap_fdatawrite_wbc(), which creates an ordered extent for inode X;<br /> <br /> 3) The unmount sequence starts from another task, we enter close_ctree()<br /> and we flush the workqueue fs_info-&gt;endio_write_workers, which waits<br /> for the ordered extent for inode X to complete and when dropping the<br /> last reference of the ordered extent, with btrfs_put_ordered_extent(),<br /> when we call btrfs_add_delayed_iput() we don&amp;#39;t add the inode to the<br /> list of delayed iputs because it has a refcount of 2, so we decrement<br /> it to 1 and return;<br /> <br /> 4) Shortly after at close_ctree() we call btrfs_run_delayed_iputs() which<br /> runs all delayed iputs, and then we set BTRFS_FS_STATE_NO_DELAYED_IPUT<br /> in the fs_info state;<br /> <br /> 5) The async reclaim worker, after calling filemap_fdatawrite_wbc(), now<br /> calls btrfs_add_delayed_iput() for inode X and there we trigger an<br /> assertion failure since the fs_info state has the flag<br /> BTRFS_FS_STATE_NO_DELAYED_IPUT set.<br /> <br /> Fix this by setting BTRFS_FS_STATE_NO_DELAYED_IPUT only after we wait for<br /> the async reclaim workers to finish, after we call cancel_work_sync() for<br /> them at close_ctree(), and by running delayed iputs after wait for the<br /> reclaim workers to finish and before setting the bit.<br /> <br /> This race was recently introduced by commit 19e60b2a95f5 ("btrfs: add<br /> extra warning if delayed iput is added when it&amp;#39;s not allowed"). Without<br /> the new validation at btrfs_add_delayed_iput(), <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/mm: Fix in_atomic() handling in do_secure_storage_access()<br /> <br /> Kernel user spaces accesses to not exported pages in atomic context<br /> incorrectly try to resolve the page fault.<br /> With debug options enabled call traces like this can be seen:<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39<br /> preempt_count: 1, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> INFO: lockdep is turned off.<br /> Preemption disabled at:<br /> [] copy_page_from_iter_atomic+0xa2/0x8a0<br /> CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39<br /> Tainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPT<br /> Tainted: [W]=WARN<br /> Hardware name: IBM 3931 A01 703 (LPAR)<br /> Call Trace:<br /> [] dump_stack_lvl+0xa2/0xe8<br /> [] __might_resched+0x292/0x2d0<br /> [] down_read+0x34/0x2d0<br /> [] do_secure_storage_access+0x108/0x360<br /> [] __do_pgm_check+0x130/0x220<br /> [] pgm_check_handler+0x114/0x160<br /> [] copy_page_from_iter_atomic+0x128/0x8a0<br /> ([] copy_page_from_iter_atomic+0x116/0x8a0)<br /> [] generic_perform_write+0x16e/0x310<br /> [] ext4_buffered_write_iter+0x84/0x160<br /> [] vfs_write+0x1c4/0x460<br /> [] ksys_write+0x7c/0x100<br /> [] __do_syscall+0x15e/0x280<br /> [] system_call+0x6e/0x90<br /> INFO: lockdep is turned off.<br /> <br /> It is not allowed to take the mmap_lock while in atomic context. Therefore<br /> handle such a secure storage access fault as if the accessed page is not<br /> mapped: the uaccess function will return -EFAULT, and the caller has to<br /> deal with this. Usually this means that the access is retried in process<br /> context, which allows to resolve the page fault (or in this case export the<br /> page).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add more checks for DSC / HUBP ONO guarantees<br /> <br /> [WHY]<br /> For non-zero DSC instances it&amp;#39;s possible that the HUBP domain required<br /> to drive it for sequential ONO ASICs isn&amp;#39;t met, potentially causing<br /> the logic to the tile to enter an undefined state leading to a system<br /> hang.<br /> <br /> [HOW]<br /> Add more checks to ensure that the HUBP domain matching the DSC instance<br /> is appropriately powered.<br /> <br /> (cherry picked from commit da63df07112e5a9857a8d2aaa04255c4206754ec)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check dce_hwseq before dereferencing it<br /> <br /> [WHAT]<br /> <br /> hws was checked for null earlier in dce110_blank_stream, indicating hws<br /> can be null, and should be checked whenever it is used.<br /> <br /> (cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)