Vulnerabilities

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 /> misc: tps6594-pfsm: Add NULL pointer check in tps6594_pfsm_probe()<br /> <br /> The returned value, pfsm-&gt;miscdev.name, from devm_kasprintf()<br /> could be NULL.<br /> A pointer check is added to prevent potential NULL pointer dereference.<br /> This is similar to the fix in commit 3027e7b15b02<br /> ("ice: Fix some null pointer dereference issues in ice_ptp.c").<br /> <br /> This issue is found by our static analysis tool.

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 /> 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 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 /> drm/tegra: Fix a possible null pointer dereference<br /> <br /> In tegra_crtc_reset(), new memory is allocated with kzalloc(), but<br /> no check is performed. Before calling __drm_atomic_helper_crtc_reset,<br /> state should be checked to prevent possible null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add null pointer check for get_first_active_display()<br /> <br /> The function mod_hdcp_hdcp1_enable_encryption() calls the function<br /> get_first_active_display(), but does not check its return value.<br /> The return value is a null pointer if the display list is empty.<br /> This will lead to a null pointer dereference in<br /> mod_hdcp_hdcp2_enable_encryption().<br /> <br /> Add a null pointer check for get_first_active_display() and return<br /> MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate()<br /> <br /> Temporarily clear the preallocation flag when explicitly requesting<br /> allocations. Pre-existing allocations are already counted against the<br /> request through mas_node_count_gfp(), but the allocations will not happen<br /> if the MA_STATE_PREALLOC flag is set. This flag is meant to avoid<br /> re-allocating in bulk allocation mode, and to detect issues with<br /> preallocation calculations.<br /> <br /> The MA_STATE_PREALLOC flag should also always be set on zero allocations<br /> so that detection of underflow allocations will print a WARN_ON() during<br /> consumption.<br /> <br /> User visible effect of this flaw is a WARN_ON() followed by a null pointer<br /> dereference when subsequent requests for larger number of nodes is<br /> ignored, such as the vma merge retry in mmap_region() caused by drivers<br /> altering the vma flags (which happens in v6.6, at least)

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