Vulnerabilities

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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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: 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 /> dm: fix a buffer overflow in ioctl processing<br /> <br /> Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the<br /> function retrieve_status:<br /> <br /> 1. The code in retrieve_status checks that the output string fits into<br /> the output buffer and writes the output string there<br /> 2. Then, the code aligns the "outptr" variable to the next 8-byte<br /> boundary:<br /> outptr = align_ptr(outptr);<br /> 3. The alignment doesn&amp;#39;t check overflow, so outptr could point past the<br /> buffer end<br /> 4. The "for" loop is iterated again, it executes:<br /> remaining = len - (outptr - outbuf);<br /> 5. If "outptr" points past "outbuf + len", the arithmetics wraps around<br /> and the variable "remaining" contains unusually high number<br /> 6. With "remaining" being high, the code writes more data past the end of<br /> the buffer<br /> <br /> Luckily, this bug has no security implications because:<br /> 1. Only root can issue device mapper ioctls<br /> 2. The commonly used libraries that communicate with device mapper<br /> (libdevmapper and devicemapper-rs) use buffer size that is aligned to<br /> 8 bytes - thus, "outptr = align_ptr(outptr)" can&amp;#39;t overshoot the input<br /> buffer and the bug can&amp;#39;t happen accidentally

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty<br /> <br /> Fall back to apic_find_highest_vector() when PID.ON is set but PIR<br /> turns out to be empty, to correctly report the highest pending interrupt<br /> from the existing IRR.<br /> <br /> In a nested VM stress test, the following WARNING fires in<br /> vmx_check_nested_events() when kvm_cpu_has_interrupt() reports a pending<br /> interrupt but the subsequent kvm_apic_has_interrupt() (which invokes<br /> vmx_sync_pir_to_irr() again) returns -1:<br /> <br /> WARNING: CPU: 99 PID: 57767 at arch/x86/kvm/vmx/nested.c:4449 vmx_check_nested_events+0x6bf/0x6e0 [kvm_intel]<br /> Call Trace:<br /> kvm_check_and_inject_events<br /> vcpu_enter_guest.constprop.0<br /> vcpu_run<br /> kvm_arch_vcpu_ioctl_run<br /> kvm_vcpu_ioctl<br /> __x64_sys_ioctl<br /> do_syscall_64<br /> entry_SYSCALL_64_after_hwframe<br /> <br /> The root cause is a race between vmx_sync_pir_to_irr() on the target vCPU<br /> and __vmx_deliver_posted_interrupt() on a sender vCPU. The sender<br /> performs two individually-atomic operations that are not a single<br /> transaction:<br /> <br /> 1. pi_test_and_set_pir(vector) -- sets the PIR bit<br /> 2. pi_test_and_set_on() -- sets PID.ON<br /> <br /> The following interleaving triggers the bug:<br /> <br /> Sender vCPU (IPI): Target vCPU (1st sync_pir_to_irr):<br /> B1: set PIR[vector]<br /> A1: pi_clear_on()<br /> A2: pi_harvest_pir() -&gt; sees B1 bit<br /> A3: xchg() -&gt; consumes bit, PIR=0<br /> (1st sync returns correct max_irr)<br /> B2: set PID.ON = 1<br /> <br /> Target vCPU (2nd sync_pir_to_irr):<br /> C1: pi_test_on() -&gt; TRUE (from B2)<br /> C2: pi_clear_on() -&gt; ON=0<br /> C3: pi_harvest_pir() -&gt; PIR empty<br /> C4: *max_irr = -1, early return<br /> IRR NOT SCANNED<br /> <br /> The interrupt is not lost (it resides in the IRR from the first sync and<br /> is recovered on the next vcpu_enter_guest() iteration), but the incorrect<br /> max_irr causes a spurious WARNING and a wasted L2 VM-Enter/VM-Exit cycle.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: core: Fix detach procedure for virtual devices in genpd<br /> <br /> If a device is attached to a PM domain through genpd_dev_pm_attach_by_id(),<br /> genpd calls pm_runtime_enable() for the corresponding virtual device that<br /> it registers. While this avoids boilerplate code in drivers, there is no<br /> corresponding call to pm_runtime_disable() in genpd_dev_pm_detach().<br /> <br /> This means these virtual devices are typically detached from its genpd,<br /> while runtime PM remains enabled for them, which is not how things are<br /> designed to work. In worst cases it may lead to critical errors, like a<br /> NULL pointer dereference bug in genpd_runtime_suspend(), which was recently<br /> reported. For another case, we may end up keeping an unnecessary vote for a<br /> performance state for the device.<br /> <br /> To fix these problems, let&amp;#39;s add this missing call to pm_runtime_disable()<br /> in genpd_dev_pm_detach().