Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/uapi: Reject coh_none PAT index for CPU cached memory in madvise<br /> <br /> Add validation in xe_vm_madvise_ioctl() to reject PAT indices with<br /> XE_COH_NONE coherency mode when applied to CPU cached memory.<br /> <br /> Using coh_none with CPU cached buffers is a security issue. When the<br /> kernel clears pages before reallocation, the clear operation stays in<br /> CPU cache (dirty). GPU with coh_none can bypass CPU caches and read<br /> stale sensitive data directly from DRAM, potentially leaking data from<br /> previously freed pages of other processes.<br /> <br /> This aligns with the existing validation in vm_bind path<br /> (xe_vm_bind_ioctl_validate_bo).<br /> <br /> v2(Matthew brost)<br /> - Add fixes<br /> - Move one debug print to better place<br /> <br /> v3(Matthew Auld)<br /> - Should be drm/xe/uapi<br /> - More Cc<br /> <br /> v4(Shuicheng Lin)<br /> - Fix kmem leak issues by the way<br /> <br /> v5<br /> - Remove kmem leak because it has been merged by another patch<br /> <br /> v6<br /> - Remove the fix which is not related to current fix<br /> <br /> v7<br /> - No change<br /> <br /> v8<br /> - Rebase<br /> <br /> v9<br /> - Limit the restrictions to iGPU<br /> <br /> v10<br /> - No change<br /> <br /> (cherry picked from commit 016ccdb674b8c899940b3944952c96a6a490d10a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: renesas: vsp1: Fix NULL pointer deref on module unload<br /> <br /> When unloading the module on gen 4, we hit a NULL pointer dereference.<br /> This is caused by the cleanup code calling vsp1_drm_cleanup() where it<br /> should be calling vsp1_vspx_cleanup().<br /> <br /> Fix this by checking the IP version and calling the drm or vspx function<br /> accordingly, the same way as the init code does.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: fix held lock freed on hfsplus_fill_super()<br /> <br /> hfsplus_fill_super() calls hfs_find_init() to initialize a search<br /> structure, which acquires tree-&gt;tree_lock. If the subsequent call to<br /> hfsplus_cat_build_key() fails, the function jumps to the out_put_root<br /> error label without releasing the lock. The later cleanup path then<br /> frees the tree data structure with the lock still held, triggering a<br /> held lock freed warning.<br /> <br /> Fix this by adding the missing hfs_find_exit(&amp;fd) call before jumping<br /> to the out_put_root error label. This ensures that tree-&gt;tree_lock is<br /> properly released on the error path.<br /> <br /> The bug was originally detected on v6.13-rc1 using an experimental<br /> static analysis tool we are developing, and we have verified that the<br /> issue persists in the latest mainline kernel. The tool is specifically<br /> designed to detect memory management issues. It is currently under active<br /> development and not yet publicly available.<br /> <br /> We confirmed the bug by runtime testing under QEMU with x86_64 defconfig,<br /> lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we<br /> used GDB to dynamically shrink the max_unistr_len parameter to 1 before<br /> hfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally<br /> return -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and<br /> exercises the faulty error path. The following warning was observed<br /> during mount:<br /> <br /> =========================<br /> WARNING: held lock freed!<br /> 7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted<br /> -------------------------<br /> mount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there!<br /> ffff888103f920b0 (&amp;tree-&gt;tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0<br /> 2 locks held by mount/174:<br /> #0: ffff888103f960e0 (&amp;type-&gt;s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40<br /> #1: ffff888103f920b0 (&amp;tree-&gt;tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0<br /> <br /> stack backtrace:<br /> CPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x82/0xd0<br /> debug_check_no_locks_freed+0x13a/0x180<br /> kfree+0x16b/0x510<br /> ? hfsplus_fill_super+0xcb4/0x18a0<br /> hfsplus_fill_super+0xcb4/0x18a0<br /> ? __pfx_hfsplus_fill_super+0x10/0x10<br /> ? srso_return_thunk+0x5/0x5f<br /> ? bdev_open+0x65f/0xc30<br /> ? srso_return_thunk+0x5/0x5f<br /> ? pointer+0x4ce/0xbf0<br /> ? trace_contention_end+0x11c/0x150<br /> ? __pfx_pointer+0x10/0x10<br /> ? srso_return_thunk+0x5/0x5f<br /> ? bdev_open+0x79b/0xc30<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? vsnprintf+0x6da/0x1270<br /> ? srso_return_thunk+0x5/0x5f<br /> ? __mutex_unlock_slowpath+0x157/0x740<br /> ? __pfx_vsnprintf+0x10/0x10<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? mark_held_locks+0x49/0x80<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? irqentry_exit+0x17b/0x5e0<br /> ? trace_irq_disable.constprop.0+0x116/0x150<br /> ? __pfx_hfsplus_fill_super+0x10/0x10<br /> ? __pfx_hfsplus_fill_super+0x10/0x10<br /> get_tree_bdev_flags+0x302/0x580<br /> ? __pfx_get_tree_bdev_flags+0x10/0x10<br /> ? vfs_parse_fs_qstr+0x129/0x1a0<br /> ? __pfx_vfs_parse_fs_qstr+0x3/0x10<br /> vfs_get_tree+0x89/0x320<br /> fc_mount+0x10/0x1d0<br /> path_mount+0x5c5/0x21c0<br /> ? __pfx_path_mount+0x10/0x10<br /> ? trace_irq_enable.constprop.0+0x116/0x150<br /> ? trace_irq_enable.constprop.0+0x116/0x150<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? kmem_cache_free+0x307/0x540<br /> ? user_path_at+0x51/0x60<br /> ? __x64_sys_mount+0x212/0x280<br /> ? srso_return_thunk+0x5/0x5f<br /> __x64_sys_mount+0x212/0x280<br /> ? __pfx___x64_sys_mount+0x10/0x10<br /> ? srso_return_thunk+0x5/0x5f<br /> ? trace_irq_enable.constprop.0+0x116/0x150<br /> ? srso_return_thunk+0x5/0x5f<br /> do_syscall_64+0x111/0x680<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7ffacad55eae<br /> Code: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8<br /> RSP: 002b<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: s3c64xx: fix NULL-deref on driver unbind<br /> <br /> A change moving DMA channel allocation from probe() back to<br /> s3c64xx_spi_prepare_transfer() failed to remove the corresponding<br /> deallocation from remove().<br /> <br /> Drop the bogus DMA channel release from remove() to avoid triggering a<br /> NULL-pointer dereference on driver unbind.<br /> <br /> This issue was flagged by Sashiko when reviewing a controller<br /> deregistration fix.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: libwx: use request_irq for VF misc interrupt<br /> <br /> Currently, request_threaded_irq() is used with a primary handler but a<br /> NULL threaded handler, while also setting the IRQF_ONESHOT flag. This<br /> specific combination triggers a WARNING since the commit aef30c8d569c<br /> ("genirq: Warn about using IRQF_ONESHOT without a threaded handler").<br /> <br /> WARNING: kernel/irq/manage.c:1502 at __setup_irq+0x4fa/0x760<br /> <br /> Fix the issue by switching to request_irq(), which is the appropriate<br /> interface or a non-threaded interrupt handler, and removing the<br /> unnecessary IRQF_ONESHOT flag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pseries/papr-hvpipe: Fix race with interrupt handler<br /> <br /> While executing -&gt;ioctl handler or -&gt;release handler, if an interrupt<br /> fires on the same cpu, then we can enter into a deadlock.<br /> <br /> This patch fixes both these handlers to take spin_lock_irq{save|restore}<br /> versions of the lock to prevent this deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: topcliff-pch: fix use-after-free on unbind<br /> <br /> Give the driver a chance to flush its queue before releasing the DMA<br /> buffers on driver unbind

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> selinux: allow multiple opens of /sys/fs/selinux/policy<br /> <br /> Currently there can only be a single open of /sys/fs/selinux/policy at<br /> any time. This allows any process to block any other process from<br /> reading the kernel policy. The original motivation seems to have been<br /> a mix of preventing an inconsistent view of the policy size and<br /> preventing userspace from allocating kernel memory without bound, but<br /> this is arguably equally bad. Eliminate the policy_opened flag and<br /> shrink the critical section that the policy mutex is held. While we<br /> are making changes here, drop a couple of extraneous BUG_ONs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> isofs: validate Rock Ridge CE continuation extent against volume size<br /> <br /> rock_continue() reads rs-&gt;cont_extent verbatim from the Rock Ridge CE<br /> record and passes it to sb_bread() without checking that the block<br /> number is within the mounted ISO 9660 volume. commit e595447e177b<br /> ("[PATCH] rock.c: handle corrupted directories") added cont_offset<br /> and cont_size rejection for the CE continuation but did not validate<br /> the extent block number itself. commit f54e18f1b831 ("isofs: Fix<br /> infinite looping over CE entries") later capped the CE chain length<br /> at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked.<br /> <br /> With a crafted ISO mounted via udisks2 (desktop optical auto-mount)<br /> or via CAP_SYS_ADMIN mount, rs-&gt;cont_extent can therefore point at<br /> an out-of-range block or at blocks belonging to an adjacent<br /> filesystem on the same block device. sb_bread() on an out-of-range<br /> block returns NULL cleanly via the block layer EIO path, so there<br /> is no memory-safety violation. For in-range reads of adjacent-<br /> filesystem data, the CE buffer is parsed as Rock Ridge records and<br /> only the text of SL sub-records reaches userspace through<br /> readlink(), which makes the info-leak channel narrow and difficult<br /> to exploit; still, rejecting the malformed CE outright matches the<br /> rejection shape already present in the same function for<br /> cont_offset and cont_size.<br /> <br /> Add an ISOFS_SB(sb)-&gt;s_nzones bounds check to rock_continue() next<br /> to the existing offset/size rejection, printing the same<br /> corrupted-directory-entry notice.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/scatterlist: fix length calculations in extract_kvec_to_sg<br /> <br /> Patch series "Fix bugs in extract_iter_to_sg()", v3.<br /> <br /> Fix bugs in the kvec and user variants of extract_iter_to_sg. This series<br /> is growing due to useful remarks made by sashiko.dev.<br /> <br /> The main bugs are:<br /> - The length for an sglist entry when extracting from<br /> a kvec can exceed the number of bytes in the page. This<br /> is obviously not intended.<br /> - When extracting a user buffer the sglist is temporarily<br /> used as a scratch buffer for extracted page pointers.<br /> If the sglist already contains some elements this scratch<br /> buffer could overlap with existing entries in the sglist.<br /> <br /> The series adds test cases to the kunit_iov_iter test that demonstrate all<br /> of these bugs. Additionally, there is a memory leak fix for the test<br /> itself.<br /> <br /> The bugs were orignally introduced into kernel v6.3 where the function<br /> lived in fs/netfs/iterator.c. It was later moved to lib/scatterlist.c in<br /> v6.5. Thus the actual fix is only marked for backports to v6.5+.<br /> <br /> <br /> This patch (of 5):<br /> <br /> When extracting from a kvec to a scatterlist, do not cross page<br /> boundaries. The required length was already calculated but not used as<br /> intended.<br /> <br /> Adjust the copied length if the loop runs out of sglist entries without<br /> extracting everything.<br /> <br /> While there, return immediately from extract_iter_to_sg if there are no<br /> sglist entries at all.<br /> <br /> A subsequent commit will add kunit test cases that demonstrate that the<br /> patch is necessary.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/efi: Fix graceful fault handling after FPU softirq changes<br /> <br /> Since commit d02198550423 ("x86/fpu: Improve crypto performance by<br /> making kernel-mode FPU reliably usable in softirqs"), kernel_fpu_begin()<br /> calls fpregs_lock() which uses local_bh_disable() instead of the<br /> previous preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count<br /> during the entire EFI runtime service call, causing in_interrupt() to<br /> return true in normal task context.<br /> <br /> The graceful page fault handler efi_crash_gracefully_on_page_fault()<br /> uses in_interrupt() to bail out for faults in real interrupt context.<br /> With SOFTIRQ_OFFSET now set, the handler always bails out, leaving EFI<br /> firmware page faults unhandled. This escalates to die() which also sees<br /> in_interrupt() as true and calls panic("Fatal exception in interrupt"),<br /> resulting in a hard system freeze. On systems with buggy firmware that<br /> triggers page faults during EFI runtime calls (e.g., accessing unmapped<br /> memory in GetTime()), this causes an unrecoverable hang instead of the<br /> expected graceful EFI_ABORTED recovery.<br /> <br /> Fix by replacing in_interrupt() with !in_task(). This preserves the<br /> original intent of bailing for interrupts or NMI faults, while no longer<br /> falsely triggering from the FPU code path&amp;#39;s local_bh_disable().<br /> <br /> [ardb: Sashiko spotted that using &amp;#39;in_hardirq() || in_nmi()&amp;#39; leaves a<br /> window where a softirq may be taken before fpregs_lock() is<br /> called, but after efi_rts_work.efi_rts_id has been assigned,<br /> and any page faults occurring in that window will then be<br /> misidentified as having been caused by the firmware. Instead,<br /> use !in_task(), which incorporates in_serving_softirq(). ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: caam - guard HMAC key hex dumps in hash_digest_key<br /> <br /> Use print_hex_dump_devel() for dumping sensitive HMAC key bytes in<br /> hash_digest_key() to avoid leaking secrets at runtime when<br /> CONFIG_DYNAMIC_DEBUG is enabled.