Vulnerabilities

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.

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().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: microchip: mpfs-ccc: fix out of bounds access during output registration<br /> <br /> UBSAN reported an out of bounds access during registration of the last<br /> two outputs. This out of bounds access occurs because space is only<br /> allocated in the hws array for two PLLs and the four output dividers<br /> that each has, but the defined IDs contain two DLLS and their two<br /> outputs each, which are not supported by the driver. The ID order is<br /> PLLs -&gt; DLLs -&gt; PLL outputs -&gt; DLL outputs. Decrement the PLL output IDs<br /> by two while adding them to the array to avoid the problem.

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.