Vulnerabilities

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

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.

Allocation of Resources Without Limits or Throttling vulnerability in Kron Technologies Kron PAM allows HTTP DoS.This issue affects Kron PAM: before 3.7.

NULL Pointer Dereference in µD3TN via non-singleton destination Endpoint Identifier allows remote attacker to reliably cause DoS

A vulnerability was found in TOTOLINK A702R 4.0.0-B20230721.1521. It has been classified as critical. This affects an unknown part of the file /boafrm/formPortFw of the component HTTP POST Request Handler. The manipulation of the argument service_type leads to buffer overflow. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.

A vulnerability was found in TOTOLINK A702R 4.0.0-B20230721.1521. It has been declared as critical. This vulnerability affects unknown code of the file /boafrm/formWlanMultipleAP of the component HTTP POST Request Handler. The manipulation of the argument submit-url leads to buffer overflow. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.