Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: prevent immediate PASID reuse case<br /> <br /> PASID resue could cause interrupt issue when process<br /> immediately runs into hw state left by previous<br /> process exited with the same PASID, it&amp;#39;s possible that<br /> page faults are still pending in the IH ring buffer when<br /> the process exits and frees up its PASID. To prevent the<br /> case, it uses idr cyclic allocator same as kernel pid&amp;#39;s.<br /> <br /> (cherry picked from commit 8f1de51f49be692de137c8525106e0fce2d1912d)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: stop reclaim before pushing AIL during unmount<br /> <br /> The unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while<br /> background reclaim and inodegc are still running. This is broken<br /> independently of any use-after-free issues - background reclaim and<br /> inodegc should not be running while the AIL is being pushed during<br /> unmount, as inodegc can dirty and insert inodes into the AIL during the<br /> flush, and background reclaim can race to abort and free dirty inodes.<br /> <br /> Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel background<br /> reclaim before pushing the AIL. Stop inodegc before cancelling<br /> m_reclaim_work because the inodegc worker can re-queue m_reclaim_work<br /> via xfs_inodegc_set_reclaimable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/pagewalk: fix race between concurrent split and refault<br /> <br /> The splitting of a PUD entry in walk_pud_range() can race with a<br /> concurrent thread refaulting the PUD leaf entry causing it to try walking<br /> a PMD range that has disappeared.<br /> <br /> An example and reproduction of this is to try reading numa_maps of a<br /> process while VFIO-PCI is setting up DMA (specifically the<br /> vfio_pin_pages_remote call) on a large BAR for that process.<br /> <br /> This will trigger a kernel BUG:<br /> vfio-pci 0000:03:00.0: enabling device (0000 -&gt; 0002)<br /> BUG: unable to handle page fault for address: ffffa23980000000<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> ...<br /> RIP: 0010:walk_pgd_range+0x3b5/0x7a0<br /> Code: 8d 43 ff 48 89 44 24 28 4d 89 ce 4d 8d a7 00 00 20 00 48 8b 4c 24<br /> 28 49 81 e4 00 00 e0 ff 49 8d 44 24 ff 48 39 c8 4c 0f 43 e3 f7 06<br /> 9f ff ff ff 75 3b 48 8b 44 24 20 48 8b 40 28 48 85 c0 74<br /> RSP: 0018:ffffac23e1ecf808 EFLAGS: 00010287<br /> RAX: 00007f44c01fffff RBX: 00007f4500000000 RCX: 00007f44ffffffff<br /> RDX: 0000000000000000 RSI: 000ffffffffff000 RDI: ffffffff93378fe0<br /> RBP: ffffac23e1ecf918 R08: 0000000000000004 R09: ffffa23980000000<br /> R10: 0000000000000020 R11: 0000000000000004 R12: 00007f44c0200000<br /> R13: 00007f44c0000000 R14: ffffa23980000000 R15: 00007f44c0000000<br /> FS: 00007fe884739580(0000) GS:ffff9b7d7a9c0000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffa23980000000 CR3: 000000c0650e2005 CR4: 0000000000770ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> __walk_page_range+0x195/0x1b0<br /> walk_page_vma+0x62/0xc0<br /> show_numa_map+0x12b/0x3b0<br /> seq_read_iter+0x297/0x440<br /> seq_read+0x11d/0x140<br /> vfs_read+0xc2/0x340<br /> ksys_read+0x5f/0xe0<br /> do_syscall_64+0x68/0x130<br /> ? get_page_from_freelist+0x5c2/0x17e0<br /> ? mas_store_prealloc+0x17e/0x360<br /> ? vma_set_page_prot+0x4c/0xa0<br /> ? __alloc_pages_noprof+0x14e/0x2d0<br /> ? __mod_memcg_lruvec_state+0x8d/0x140<br /> ? __lruvec_stat_mod_folio+0x76/0xb0<br /> ? __folio_mod_stat+0x26/0x80<br /> ? do_anonymous_page+0x705/0x900<br /> ? __handle_mm_fault+0xa8d/0x1000<br /> ? __count_memcg_events+0x53/0xf0<br /> ? handle_mm_fault+0xa5/0x360<br /> ? do_user_addr_fault+0x342/0x640<br /> ? arch_exit_to_user_mode_prepare.constprop.0+0x16/0xa0<br /> ? irqentry_exit_to_user_mode+0x24/0x100<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fe88464f47e<br /> Code: c0 e9 b6 fe ff ff 50 48 8d 3d be 07 0b 00 e8 69 01 02 00 66 0f 1f<br /> 84 00 00 00 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 0f 05 3d 00<br /> f0 ff ff 77 5a c3 66 0f 1f 84 00 00 00 00 00 48 83 ec 28<br /> RSP: 002b:00007ffe6cd9a9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007fe88464f47e<br /> RDX: 0000000000020000 RSI: 00007fe884543000 RDI: 0000000000000003<br /> RBP: 00007fe884543000 R08: 00007fe884542010 R09: 0000000000000000<br /> R10: fffffffffffffbc5 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000<br /> <br /> <br /> Fix this by validating the PUD entry in walk_pmd_range() using a stable<br /> snapshot (pudp_get()). If the PUD is not present or is a leaf, retry the<br /> walk via ACTION_AGAIN instead of descending further. This mirrors the<br /> retry logic in walk_pte_range(), which lets walk_pmd_range() retry if the<br /> PTE is not being got by pte_offset_map_lock().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: publish jinode after initialization<br /> <br /> ext4_inode_attach_jinode() publishes ei-&gt;jinode to concurrent users.<br /> It used to set ei-&gt;jinode before jbd2_journal_init_jbd_inode(),<br /> allowing a reader to observe a non-NULL jinode with i_vfs_inode<br /> still unset.<br /> <br /> The fast commit flush path can then pass this jinode to<br /> jbd2_wait_inode_data(), which dereferences i_vfs_inode-&gt;i_mapping and<br /> may crash.<br /> <br /> Below is the crash I observe:<br /> ```<br /> BUG: unable to handle page fault for address: 000000010beb47f4<br /> PGD 110e51067 P4D 110e51067 PUD 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014<br /> RIP: 0010:xas_find_marked+0x3d/0x2e0<br /> Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02<br /> RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246<br /> RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003<br /> RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10<br /> RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec<br /> R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000<br /> R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88<br /> FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> filemap_get_folios_tag+0x87/0x2a0<br /> __filemap_fdatawait_range+0x5f/0xd0<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __schedule+0x3e7/0x10c0<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? preempt_count_sub+0x5f/0x80<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? cap_safe_nice+0x37/0x70<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? preempt_count_sub+0x5f/0x80<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> filemap_fdatawait_range_keep_errors+0x12/0x40<br /> ext4_fc_commit+0x697/0x8b0<br /> ? ext4_file_write_iter+0x64b/0x950<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? preempt_count_sub+0x5f/0x80<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? vfs_write+0x356/0x480<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? preempt_count_sub+0x5f/0x80<br /> ext4_sync_file+0xf7/0x370<br /> do_fsync+0x3b/0x80<br /> ? syscall_trace_enter+0x108/0x1d0<br /> __x64_sys_fdatasync+0x16/0x20<br /> do_syscall_64+0x62/0x2c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ...<br /> ```<br /> <br /> Fix this by initializing the jbd2_inode first.<br /> Use smp_wmb() and WRITE_ONCE() to publish ei-&gt;jinode after<br /> initialization. Readers use READ_ONCE() to fetch the pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: replace BUG_ON with proper error handling in ext4_read_inline_folio<br /> <br /> Replace BUG_ON() with proper error handling when inline data size<br /> exceeds PAGE_SIZE. This prevents kernel panic and allows the system to<br /> continue running while properly reporting the filesystem corruption.<br /> <br /> The error is logged via ext4_error_inode(), the buffer head is released<br /> to prevent memory leak, and -EFSCORRUPTED is returned to indicate<br /> filesystem corruption.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: convert inline data to extents when truncate exceeds inline size<br /> <br /> Add a check in ext4_setattr() to convert files from inline data storage<br /> to extent-based storage when truncate() grows the file size beyond the<br /> inline capacity. This prevents the filesystem from entering an<br /> inconsistent state where the inline data flag is set but the file size<br /> exceeds what can be stored inline.<br /> <br /> Without this fix, the following sequence causes a kernel BUG_ON():<br /> <br /> 1. Mount filesystem with inode that has inline flag set and small size<br /> 2. truncate(file, 50MB) - grows size but inline flag remains set<br /> 3. sendfile() attempts to write data<br /> 4. ext4_write_inline_data() hits BUG_ON(write_size &gt; inline_capacity)<br /> <br /> The crash occurs because ext4_write_inline_data() expects inline storage<br /> to accommodate the write, but the actual inline capacity (~60 bytes for<br /> i_block + ~96 bytes for xattrs) is far smaller than the file size and<br /> write request.<br /> <br /> The fix checks if the new size from setattr exceeds the inode&amp;#39;s actual<br /> inline capacity (EXT4_I(inode)-&gt;i_inline_size) and converts the file to<br /> extent-based storage before proceeding with the size change.<br /> <br /> This addresses the root cause by ensuring the inline data flag and file<br /> size remain consistent during truncate operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: avoid dereferencing log items after push callbacks<br /> <br /> After xfsaild_push_item() calls iop_push(), the log item may have been<br /> freed if the AIL lock was dropped during the push. Background inode<br /> reclaim or the dquot shrinker can free the log item while the AIL lock<br /> is not held, and the tracepoints in the switch statement dereference<br /> the log item after iop_push() returns.<br /> <br /> Fix this by capturing the log item type, flags, and LSN before calling<br /> xfsaild_push_item(), and introducing a new xfs_ail_push_class trace<br /> event class that takes these pre-captured values and the ailp pointer<br /> instead of the log item pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: save ailp before dropping the AIL lock in push callbacks<br /> <br /> In xfs_inode_item_push() and xfs_qm_dquot_logitem_push(), the AIL lock<br /> is dropped to perform buffer IO. Once the cluster buffer no longer<br /> protects the log item from reclaim, the log item may be freed by<br /> background reclaim or the dquot shrinker. The subsequent spin_lock()<br /> call dereferences lip-&gt;li_ailp, which is a use-after-free.<br /> <br /> Fix this by saving the ailp pointer in a local variable while the AIL<br /> lock is held and the log item is guaranteed to be valid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free and NULL deref in smb_grant_oplock()<br /> <br /> smb_grant_oplock() has two issues in the oplock publication sequence:<br /> <br /> 1) opinfo is linked into ci-&gt;m_op_list (via opinfo_add) before<br /> add_lease_global_list() is called. If add_lease_global_list()<br /> fails (kmalloc returns NULL), the error path frees the opinfo<br /> via __free_opinfo() while it is still linked in ci-&gt;m_op_list.<br /> Concurrent m_op_list readers (opinfo_get_list, or direct iteration<br /> in smb_break_all_levII_oplock) dereference the freed node.<br /> <br /> 2) opinfo-&gt;o_fp is assigned after add_lease_global_list() publishes<br /> the opinfo on the global lease list. A concurrent<br /> find_same_lease_key() can walk the lease list and dereference<br /> opinfo-&gt;o_fp-&gt;f_ci while o_fp is still NULL.<br /> <br /> Fix by restructuring the publication sequence to eliminate post-publish<br /> failure:<br /> <br /> - Set opinfo-&gt;o_fp before any list publication (fixes NULL deref).<br /> - Preallocate lease_table via alloc_lease_table() before opinfo_add()<br /> so add_lease_global_list() becomes infallible after publication.<br /> - Keep the original m_op_list publication order (opinfo_add before<br /> lease list) so concurrent opens via same_client_has_lease() and<br /> opinfo_get_list() still see the in-flight grant.<br /> - Use opinfo_put() instead of __free_opinfo() on err_out so that<br /> the RCU-deferred free path is used.<br /> <br /> This also requires splitting add_lease_global_list() to take a<br /> preallocated lease_table and changing its return type from int to void,<br /> since it can no longer fail.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: avoid use of half-online-committed context<br /> <br /> One major usage of damon_call() is online DAMON parameters update. It is<br /> done by calling damon_commit_ctx() inside the damon_call() callback<br /> function. damon_commit_ctx() can fail for two reasons: 1) invalid<br /> parameters and 2) internal memory allocation failures. In case of<br /> failures, the damon_ctx that attempted to be updated (commit destination)<br /> can be partially updated (or, corrupted from a perspective), and therefore<br /> shouldn&amp;#39;t be used anymore. The function only ensures the damon_ctx object<br /> can safely deallocated using damon_destroy_ctx().<br /> <br /> The API callers are, however, calling damon_commit_ctx() only after<br /> asserting the parameters are valid, to avoid damon_commit_ctx() fails due<br /> to invalid input parameters. But it can still theoretically fail if the<br /> internal memory allocation fails. In the case, DAMON may run with the<br /> partially updated damon_ctx. This can result in unexpected behaviors<br /> including even NULL pointer dereference in case of damos_commit_dests()<br /> failure [1]. Such allocation failure is arguably too small to fail, so<br /> the real world impact would be rare. But, given the bad consequence, this<br /> needs to be fixed.<br /> <br /> Avoid such partially-committed (maybe-corrupted) damon_ctx use by saving<br /> the damon_commit_ctx() failure on the damon_ctx object. For this,<br /> introduce damon_ctx-&gt;maybe_corrupted field. damon_commit_ctx() sets it<br /> when it is failed. kdamond_call() checks if the field is set after each<br /> damon_call_control-&gt;fn() is executed. If it is set, ignore remaining<br /> callback requests and return. All kdamond_call() callers including<br /> kdamond_fn() also check the maybe_corrupted field right after<br /> kdamond_call() invocations. If the field is set, break the kdamond_fn()<br /> main loop so that DAMON sill doesn&amp;#39;t use the context that might be<br /> corrupted.<br /> <br /> [sj@kernel.org: let kdamond_call() with cancel regardless of maybe_corrupted]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix use-after-free in update_super_work when racing with umount<br /> <br /> Commit b98535d09179 ("ext4: fix bug_on in start_this_handle during umount<br /> filesystem") moved ext4_unregister_sysfs() before flushing s_sb_upd_work<br /> to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups<br /> reads during unmount. However, this introduced a use-after-free because<br /> update_super_work calls ext4_notify_error_sysfs() -&gt; sysfs_notify() which<br /> accesses the kobject&amp;#39;s kernfs_node after it has been freed by kobject_del()<br /> in ext4_unregister_sysfs():<br /> <br /> update_super_work ext4_put_super<br /> ----------------- --------------<br /> ext4_unregister_sysfs(sb)<br /> kobject_del(&amp;sbi-&gt;s_kobj)<br /> __kobject_del()<br /> sysfs_remove_dir()<br /> kobj-&gt;sd = NULL<br /> sysfs_put(sd)<br /> kernfs_put() // RCU free<br /> ext4_notify_error_sysfs(sbi)<br /> sysfs_notify(&amp;sbi-&gt;s_kobj)<br /> kn = kobj-&gt;sd // stale pointer<br /> kernfs_get(kn) // UAF on freed kernfs_node<br /> ext4_journal_destroy()<br /> flush_work(&amp;sbi-&gt;s_sb_upd_work)<br /> <br /> Instead of reordering the teardown sequence, fix this by making<br /> ext4_notify_error_sysfs() detect that sysfs has already been torn down<br /> by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call<br /> in that case. A dedicated mutex (s_error_notify_mutex) serializes<br /> ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs()<br /> to prevent TOCTOU races where the kobject could be deleted between the<br /> state_in_sysfs check and the sysfs_notify() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: reject mount if bigalloc with s_first_data_block != 0<br /> <br /> bigalloc with s_first_data_block != 0 is not supported, reject mounting<br /> it.