Vulnerabilities

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

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 /> fuse: fix runtime warning on truncate_folio_batch_exceptionals()<br /> <br /> The WARN_ON_ONCE is introduced on truncate_folio_batch_exceptionals() to<br /> capture whether the filesystem has removed all DAX entries or not.<br /> <br /> And the fix has been applied on the filesystem xfs and ext4 by the commit<br /> 0e2f80afcfa6 ("fs/dax: ensure all pages are idle prior to filesystem<br /> unmount").<br /> <br /> Apply the missed fix on filesystem fuse to fix the runtime warning:<br /> <br /> [ 2.011450] ------------[ cut here ]------------<br /> [ 2.011873] WARNING: CPU: 0 PID: 145 at mm/truncate.c:89 truncate_folio_batch_exceptionals+0x272/0x2b0<br /> [ 2.012468] Modules linked in:<br /> [ 2.012718] CPU: 0 UID: 1000 PID: 145 Comm: weston Not tainted 6.16.0-rc2-WSL2-STABLE #2 PREEMPT(undef)<br /> [ 2.013292] RIP: 0010:truncate_folio_batch_exceptionals+0x272/0x2b0<br /> [ 2.013704] Code: 48 63 d0 41 29 c5 48 8d 1c d5 00 00 00 00 4e 8d 6c 2a 01 49 c1 e5 03 eb 09 48 83 c3 08 49 39 dd 74 83 41 f6 44 1c 08 01 74 ef 0b 49 8b 34 1e 48 89 ef e8 10 a2 17 00 eb df 48 8b 7d 00 e8 35<br /> [ 2.014845] RSP: 0018:ffffa47ec33f3b10 EFLAGS: 00010202<br /> [ 2.015279] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> [ 2.015884] RDX: 0000000000000000 RSI: ffffa47ec33f3ca0 RDI: ffff98aa44f3fa80<br /> [ 2.016377] RBP: ffff98aa44f3fbf0 R08: ffffa47ec33f3ba8 R09: 0000000000000000<br /> [ 2.016942] R10: 0000000000000001 R11: 0000000000000000 R12: ffffa47ec33f3ca0<br /> [ 2.017437] R13: 0000000000000008 R14: ffffa47ec33f3ba8 R15: 0000000000000000<br /> [ 2.017972] FS: 000079ce006afa40(0000) GS:ffff98aade441000(0000) knlGS:0000000000000000<br /> [ 2.018510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 2.018987] CR2: 000079ce03e74000 CR3: 000000010784f006 CR4: 0000000000372eb0<br /> [ 2.019518] Call Trace:<br /> [ 2.019729] <br /> [ 2.019901] truncate_inode_pages_range+0xd8/0x400<br /> [ 2.020280] ? timerqueue_add+0x66/0xb0<br /> [ 2.020574] ? get_nohz_timer_target+0x2a/0x140<br /> [ 2.020904] ? timerqueue_add+0x66/0xb0<br /> [ 2.021231] ? timerqueue_del+0x2e/0x50<br /> [ 2.021646] ? __remove_hrtimer+0x39/0x90<br /> [ 2.022017] ? srso_alias_untrain_ret+0x1/0x10<br /> [ 2.022497] ? psi_group_change+0x136/0x350<br /> [ 2.023046] ? _raw_spin_unlock+0xe/0x30<br /> [ 2.023514] ? finish_task_switch.isra.0+0x8d/0x280<br /> [ 2.024068] ? __schedule+0x532/0xbd0<br /> [ 2.024551] fuse_evict_inode+0x29/0x190<br /> [ 2.025131] evict+0x100/0x270<br /> [ 2.025641] ? _atomic_dec_and_lock+0x39/0x50<br /> [ 2.026316] ? __pfx_generic_delete_inode+0x10/0x10<br /> [ 2.026843] __dentry_kill+0x71/0x180<br /> [ 2.027335] dput+0xeb/0x1b0<br /> [ 2.027725] __fput+0x136/0x2b0<br /> [ 2.028054] __x64_sys_close+0x3d/0x80<br /> [ 2.028469] do_syscall_64+0x6d/0x1b0<br /> [ 2.028832] ? clear_bhb_loop+0x30/0x80<br /> [ 2.029182] ? clear_bhb_loop+0x30/0x80<br /> [ 2.029533] ? clear_bhb_loop+0x30/0x80<br /> [ 2.029902] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 2.030423] RIP: 0033:0x79ce03d0d067<br /> [ 2.030820] Code: b8 ff ff ff ff e9 3e ff ff ff 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 c3 a7 f8 ff<br /> [ 2.032354] RSP: 002b:00007ffef0498948 EFLAGS: 00000246 ORIG_RAX: 0000000000000003<br /> [ 2.032939] RAX: ffffffffffffffda RBX: 00007ffef0498960 RCX: 000079ce03d0d067<br /> [ 2.033612] RDX: 0000000000000003 RSI: 0000000000001000 RDI: 000000000000000d<br /> [ 2.034289] RBP: 00007ffef0498a30 R08: 000000000000000d R09: 0000000000000000<br /> [ 2.034944] R10: 00007ffef0498978 R11: 0000000000000246 R12: 0000000000000001<br /> [ 2.035610] R13: 00007ffef0498960 R14: 000079ce03e09ce0 R15: 0000000000000003<br /> [ 2.036301] <br /> [ 2.036532] ---[ end trace 0000000000000000 ]---

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix taking invalid lock on wedge<br /> <br /> If device wedges on e.g. GuC upload, the submission is not yet enabled<br /> and the state is not even initialized. Protect the wedge call so it does<br /> nothing in this case. It fixes the following splat:<br /> <br /> [] xe 0000:bf:00.0: [drm] device wedged, needs recovery<br /> [] ------------[ cut here ]------------<br /> [] DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)<br /> [] WARNING: CPU: 48 PID: 312 at kernel/locking/mutex.c:564 __mutex_lock+0x8a1/0xe60<br /> ...<br /> [] RIP: 0010:__mutex_lock+0x8a1/0xe60<br /> [] mutex_lock_nested+0x1b/0x30<br /> [] xe_guc_submit_wedge+0x80/0x2b0 [xe]

A vulnerability has been found in D-Link DCS-6010L 1.15.03 and classified as problematic. Affected by this vulnerability is an unknown functionality of the file /vb.htm of the component Management Application. The manipulation of the argument paratest leads to cross site scripting. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. This vulnerability only affects products that are no longer supported by the maintainer.

Improper Neutralization of Input During Web Page Generation (XSS or &amp;#39;Cross-site Scripting&amp;#39;) vulnerability in Kron Technologies Kron PAM allows Stored XSS.This issue affects Kron PAM: before 3.7.