Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima: verify the previous kernel&amp;#39;s IMA buffer lies in addressable RAM<br /> <br /> Patch series "Address page fault in ima_restore_measurement_list()", v3.<br /> <br /> When the second-stage kernel is booted via kexec with a limiting command<br /> line such as "mem=" we observe a pafe fault that happens.<br /> <br /> BUG: unable to handle page fault for address: ffff97793ff47000<br /> RIP: ima_restore_measurement_list+0xdc/0x45a<br /> #PF: error_code(0x0000) not-present page<br /> <br /> This happens on x86_64 only, as this is already fixed in aarch64 in<br /> commit: cbf9c4b9617b ("of: check previous kernel&amp;#39;s ima-kexec-buffer<br /> against memory bounds")<br /> <br /> <br /> This patch (of 3):<br /> <br /> When the second-stage kernel is booted with a limiting command line (e.g. <br /> "mem="), the IMA measurement buffer handed over from the previous<br /> kernel may fall outside the addressable RAM of the new kernel. Accessing<br /> such a buffer can fault during early restore.<br /> <br /> Introduce a small generic helper, ima_validate_range(), which verifies<br /> that a physical [start, end] range for the previous-kernel IMA buffer lies<br /> within addressable memory:<br /> - On x86, use pfn_range_is_mapped().<br /> - On OF based architectures, use page_is_ram().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: handle attr_set_size() errors when truncating files<br /> <br /> If attr_set_size() fails while truncating down, the error is silently<br /> ignored and the inode may be left in an inconsistent state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: ti_fpc202: fix a potential memory leak in probe function<br /> <br /> Use for_each_child_of_node_scoped() to simplify the code and ensure the<br /> device node reference is automatically released when the loop scope<br /> ends.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: bcm_vk: Fix possible null-pointer dereferences in bcm_vk_read()<br /> <br /> In the function bcm_vk_read(), the pointer entry is checked, indicating<br /> that it can be NULL. If entry is NULL and rc is set to -EMSGSIZE, the<br /> following code may cause null-pointer dereferences:<br /> <br /> struct vk_msg_blk tmp_msg = entry-&gt;to_h_msg[0];<br /> set_msg_id(&amp;tmp_msg, entry-&gt;usr_msg_id);<br /> tmp_msg.size = entry-&gt;to_h_blks - 1;<br /> <br /> To prevent these possible null-pointer dereferences, copy to_h_msg,<br /> usr_msg_id, and to_h_blks from iter into temporary variables, and return<br /> these temporary variables to the application instead of accessing them<br /> through a potentially NULL entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: nlink overflow in jfs_rename<br /> <br /> If nlink is maximal for a directory (-1) and inside that directory you<br /> perform a rename for some child directory (not moving from the parent),<br /> then the nlink of the first directory is first incremented and later<br /> decremented. Normally this is fine, but when nlink = -1 this causes a<br /> wrap around to 0, and then drop_nlink issues a warning.<br /> <br /> After applying the patch syzbot no longer issues any warnings. I also<br /> ran some basic fs tests to look for any regressions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/ras: Move ras data alloc before bad page check<br /> <br /> In the rare event if eeprom has only invalid address entries,<br /> allocation is skipped, this causes following NULL pointer issue<br /> [ 547.103445] BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> [ 547.118897] #PF: supervisor read access in kernel mode<br /> [ 547.130292] #PF: error_code(0x0000) - not-present page<br /> [ 547.141689] PGD 124757067 P4D 0<br /> [ 547.148842] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 547.158504] CPU: 49 PID: 8167 Comm: cat Tainted: G OE 6.8.0-38-generic #38-Ubuntu<br /> [ 547.177998] Hardware name: Supermicro AS -8126GS-TNMR/H14DSG-OD, BIOS 1.7 09/12/2025<br /> [ 547.195178] RIP: 0010:amdgpu_ras_sysfs_badpages_read+0x2f2/0x5d0 [amdgpu]<br /> [ 547.210375] Code: e8 63 78 82 c0 45 31 d2 45 3b 75 08 48 8b 45 a0 73 44 44 89 f1 48 8b 7d 88 48 89 ca 48 c1 e2 05 48 29 ca 49 8b 4d 00 48 01 d1 83 79 10 00 74 17 49 63 f2 48 8b 49 08 41 83 c2 01 48 8d 34 76<br /> [ 547.252045] RSP: 0018:ffa0000067287ac0 EFLAGS: 00010246<br /> [ 547.263636] RAX: ff11000167c28130 RBX: ff11000127600000 RCX: 0000000000000000<br /> [ 547.279467] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ff11000125b1c800<br /> [ 547.295298] RBP: ffa0000067287b50 R08: 0000000000000000 R09: 0000000000000000<br /> [ 547.311129] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000<br /> [ 547.326959] R13: ff11000217b1de00 R14: 0000000000000000 R15: 0000000000000092<br /> [ 547.342790] FS: 0000746e59d14740(0000) GS:ff11017dfda80000(0000) knlGS:0000000000000000<br /> [ 547.360744] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 547.373489] CR2: 0000000000000010 CR3: 000000019585e001 CR4: 0000000000f71ef0<br /> [ 547.389321] PKRU: 55555554<br /> [ 547.395316] Call Trace:<br /> [ 547.400737] <br /> [ 547.405386] ? show_regs+0x6d/0x80<br /> [ 547.412929] ? __die+0x24/0x80<br /> [ 547.419697] ? page_fault_oops+0x99/0x1b0<br /> [ 547.428588] ? do_user_addr_fault+0x2ee/0x6b0<br /> [ 547.438249] ? exc_page_fault+0x83/0x1b0<br /> [ 547.446949] ? asm_exc_page_fault+0x27/0x30<br /> [ 547.456225] ? amdgpu_ras_sysfs_badpages_read+0x2f2/0x5d0 [amdgpu]<br /> [ 547.470040] ? mas_wr_modify+0xcd/0x140<br /> [ 547.478548] sysfs_kf_bin_read+0x63/0xb0<br /> [ 547.487248] kernfs_file_read_iter+0xa1/0x190<br /> [ 547.496909] kernfs_fop_read_iter+0x25/0x40<br /> [ 547.506182] vfs_read+0x255/0x390<br /> <br /> This also result in space left assigned to negative values.<br /> Moving data alloc call before bad page check resolves both the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix NULL pointer issue buffer funcs<br /> <br /> If SDMA block not enabled, buffer_funcs will not initialize,<br /> fix the null pointer issue if buffer_funcs not initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/buffer: add alert in try_to_free_buffers() for folios without buffers<br /> <br /> try_to_free_buffers() can be called on folios with no buffers attached<br /> when filemap_release_folio() is invoked on a folio belonging to a mapping<br /> with AS_RELEASE_ALWAYS set but no release_folio operation defined.<br /> <br /> In such cases, folio_needs_release() returns true because of the<br /> AS_RELEASE_ALWAYS flag, but the folio has no private buffer data. This<br /> causes try_to_free_buffers() to call drop_buffers() on a folio with no<br /> buffers, leading to a null pointer dereference.<br /> <br /> Adding a check in try_to_free_buffers() to return early if the folio has no<br /> buffers attached, with WARN_ON_ONCE() to alert about the misconfiguration.<br /> This provides defensive hardening.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix user_ref race between scrub and refill paths<br /> <br /> The io_zcrx_put_niov_uref() function uses a non-atomic<br /> check-then-decrement pattern (atomic_read followed by separate<br /> atomic_dec) to manipulate user_refs. This is serialized against other<br /> callers by rq_lock, but io_zcrx_scrub() modifies the same counter with<br /> atomic_xchg() WITHOUT holding rq_lock.<br /> <br /> On SMP systems, the following race exists:<br /> <br /> CPU0 (refill, holds rq_lock) CPU1 (scrub, no rq_lock)<br /> put_niov_uref:<br /> atomic_read(uref) - 1<br /> // window opens<br /> atomic_xchg(uref, 0) - 1<br /> return_niov_freelist(niov) [PUSH #1]<br /> // window closes<br /> atomic_dec(uref) - wraps to -1<br /> returns true<br /> return_niov(niov)<br /> return_niov_freelist(niov) [PUSH #2: DOUBLE-FREE]<br /> <br /> The same niov is pushed to the freelist twice, causing free_count to<br /> exceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds<br /> write (a u32 value) past the kvmalloc&amp;#39;d freelist array into the adjacent<br /> slab object.<br /> <br /> Fix this by replacing the non-atomic read-then-dec in<br /> io_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically<br /> tests and decrements user_refs. This makes the operation safe against<br /> concurrent atomic_xchg from scrub without requiring scrub to acquire<br /> rq_lock.<br /> <br /> [pavel: removed a warning and a comment]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: ensure sb-&gt;s_fs_info is always cleaned up<br /> <br /> When hfsplus was converted to the new mount api a bug was introduced by<br /> changing the allocation pattern of sb-&gt;s_fs_info. If setup_bdev_super()<br /> fails after a new superblock has been allocated by sget_fc(), but before<br /> hfsplus_fill_super() takes ownership of the filesystem-specific s_fs_info<br /> data it was leaked.<br /> <br /> Fix this by freeing sb-&gt;s_fs_info in hfsplus_kill_super().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> most: core: fix resource leak in most_register_interface error paths<br /> <br /> The function most_register_interface() did not correctly release resources<br /> if it failed early (before registering the device). In these cases, it<br /> returned an error code immediately, leaking the memory allocated for the<br /> interface.<br /> <br /> Fix this by initializing the device early via device_initialize() and<br /> calling put_device() on all error paths.<br /> <br /> The most_register_interface() is expected to call put_device() on<br /> error which frees the resources allocated in the caller. The<br /> put_device() either calls release_mdev() or dim2_release(),<br /> depending on the caller.<br /> <br /> Switch to using device_add() instead of device_register() to handle<br /> the split initialization.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band()<br /> <br /> Simplify the code by using device managed memory allocations.<br /> <br /> This also fixes a memory leak in rtw_register_hw(). The supported bands<br /> were not freed in the error path.<br /> <br /> Copied from commit 145df52a8671 ("wifi: rtw89: Convert<br /> rtw89_core_set_supported_band to use devm_*").