Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Clear __hyp_running_vcpu when flushing the pKVM hyp vCPU<br /> <br /> flush_hyp_vcpu() copies the host vCPU context into the hyp&amp;#39;s private<br /> vCPU on every run. ctxt_to_vcpu() expects a guest context to have a<br /> NULL __hyp_running_vcpu, which is only ever set on the host context, so<br /> that it resolves the vCPU via container_of(). While this is generally<br /> the case, flush_hyp_vcpu() copies the context verbatim and does not<br /> enforce this, so a value provided by the host is dereferenced at EL2<br /> (host -&gt; EL2).<br /> <br /> Fix by clearing __hyp_running_vcpu after the copy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU<br /> <br /> flush_hyp_vcpu() copies the host vGIC state into the hyp&amp;#39;s private vCPU<br /> on every run. The vGIC list register save and restore use used_lrs as<br /> their loop bound and expect it to stay within the number of implemented<br /> list registers. While this is generally the case, flush_hyp_vcpu()<br /> copies vgic_v3 verbatim and does not enforce this, so a value provided<br /> by the host is used at EL2 to index vgic_lr[] and access ICH_LR_EL2<br /> (host -&gt; EL2).<br /> <br /> Fix by clamping used_lrs to the number of implemented list registers<br /> after the copy, as the trusted path already does in<br /> vgic_flush_lr_state(). The number of implemented list registers is<br /> constant after init, so it is replicated once from<br /> kvm_vgic_global_state.nr_lr into hyp_gicv3_nr_lr rather than read on<br /> every entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: nv: Avoid dereferencing NULL VNCR pseudo-TLB<br /> <br /> VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions,<br /> and either can race against a vcpu not being onlined yet (no pseudo-TLB<br /> allocated). Similarly, the TLB might be invalid, and the invalidation<br /> should be skipped in this case.<br /> <br /> Both kvm_invalidate_vncr_ipa() and kvm_invalidate_vncr_va() are<br /> expected to perform the same checks, except that the latter doesn&amp;#39;t<br /> check for the allocation and blindly dereferences the pointer.<br /> <br /> Solve this by introducing a new iterator built on top of the usual<br /> kvm_for_each_vcpu() that checks for both of the above conditions,<br /> and convert the two users to it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Set upper bounds on cache invalidation entry_num and entry_len<br /> <br /> iommufd_hwpt_invalidate() takes a user-controlled entry_num and entry_len,<br /> each bounded only by U32_MAX. An entry_len beyond the kernel&amp;#39;s struct size<br /> makes the copy helper verify the extra bytes are zero, scanning that excess<br /> in one uninterruptible pass; a multi-gigabyte value over zeroed user memory<br /> trips the soft-lockup watchdog.<br /> <br /> A large entry_num is the other half, driving the backend invalidation loop<br /> with no reschedule. The VT-d nested handler, for one, copies each entry and<br /> flushes caches per iteration, pinning the CPU on a non-preemptible kernel.<br /> <br /> Cap both in the ioctl. entry_len is held under PAGE_SIZE, above any request<br /> struct, and entry_num under 1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Set veventq_depth upper bound<br /> <br /> iommufd_veventq_alloc() accepts any !0 veventq_depth from userspace, with<br /> an upper bound at U32_MAX.<br /> <br /> This leaves a vulnerability where userspace can allocate excessively large<br /> queues to exhaust kernel memory reserves.<br /> <br /> Cap the veventq_depth (maximum number of entries) to 1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Move vevent memory allocation outside spinlock<br /> <br /> The veventq memory allocation happens inside the spinlock. Given its depth<br /> is decided by the user space, this leaves a vulnerability, where userspace<br /> can allocate large queues to exhaust atomic memory reserves.<br /> <br /> Move the allocation outside the spinlock and use GFP_NOWAIT, which can fail<br /> fast under memory pressure without dipping into the GFP_ATOMIC reserves or<br /> direct-reclaiming from the threaded IRQ handler. On allocation failure,<br /> queue the lost_events_header (so userspace learns of the drop) and return<br /> -ENOMEM so the caller learns of the kernel-side memory pressure.<br /> <br /> This is intentionally distinct from the queue-overflow path, which also<br /> queues the lost_events_header but returns 0: a full queue is an expected<br /> userspace-pacing condition rather than a kernel error.<br /> <br /> A subsequent change will cap the upper bound of the veventq_depth.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Break the loop on failure in iommufd_fault_fops_read()<br /> <br /> On a copy_to_user() failure inside the inner list_for_each_entry, only the<br /> inner loop breaks; the outer while re-fetches the just-restored fault group<br /> and retries the failing copy_to_user() forever, spinning the reader at 100%<br /> CPU with fault-&gt;mutex held.<br /> <br /> Check rc after the inner loop and break the outer while as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count<br /> <br /> rmi_f30_map_gpios() allocates gpioled_key_map with<br /> min(gpioled_count, TRACKSTICK_RANGE_END) == at most 6 entries, but<br /> rmi_f30_attention() iterates the full f30-&gt;gpioled_count (device query<br /> register, range 0..31) and dereferences gpioled_key_map[i], and<br /> input-&gt;keycodemax is set to the full gpioled_count while input-&gt;keycode<br /> points at the 6-entry allocation.<br /> <br /> A device that reports gpioled_count &gt; 6 with GPIO support enabled<br /> therefore causes an out-of-bounds read on the attention interrupt and<br /> out-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls,<br /> which bound the index only against keycodemax. This is the same defect<br /> as the F3A handler, which was copied from F30.<br /> <br /> Size the keymap for the full gpioled_count; the mapping loop still<br /> assigns only the first min(gpioled_count, TRACKSTICK_RANGE_END) entries.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count<br /> <br /> rmi_f3a_initialize() takes the GPIO count from the device query register<br /> (f3a-&gt;gpio_count = buf &amp; RMI_F3A_GPIO_COUNT, range 0..127).<br /> rmi_f3a_map_gpios() then allocates gpio_key_map with<br /> min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but<br /> rmi_f3a_attention() iterates the full gpio_count and dereferences<br /> gpio_key_map[i], and input-&gt;keycodemax is set to the full gpio_count<br /> while input-&gt;keycode points at the 6-entry allocation.<br /> <br /> A device that reports gpio_count &gt; 6 therefore causes an out-of-bounds<br /> read of gpio_key_map[] on every attention interrupt, and out-of-bounds<br /> accesses through the input core&amp;#39;s default keymap ioctls: EVIOCGKEYCODE<br /> reads past the buffer (leaking adjacent slab memory to user space) and<br /> EVIOCSKEYCODE writes a caller-controlled value past it, for any process<br /> able to open the evdev node, since input_default_getkeycode() and<br /> input_default_setkeycode() only bound the index against keycodemax.<br /> <br /> Size the keymap for the full gpio_count. The mapping loop is unchanged:<br /> it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END)<br /> entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills)<br /> and are skipped when reporting.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: imx-lpi2c: mark I2C adapter when hardware is powered down<br /> <br /> On some i.MX platforms, certain I2C client drivers keep a periodic<br /> workqueue which continues to trigger I2C transfers.<br /> <br /> During system suspend/resume, there exists a time window between:<br /> - suspend_noirq and the system entering suspend<br /> - the system starting to resume and resume_noirq<br /> <br /> In this window, the I2C controller resources such as clock and pinctrl<br /> may already be disabled or not yet restored.<br /> <br /> If a workqueue triggers an I2C transfer in this period, the driver<br /> attempts to access I2C registers while the hardware resources are<br /> unavailable, which may lead to system hang.<br /> <br /> Mark the I2C adapter as suspended during noirq suspend and block new<br /> transfers until resume, ensuring that I2C transfers are only issued<br /> when hardware resources are available.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: core: fix adapter deregistration race<br /> <br /> Adapters can be looked up by their id using i2c_get_adapter() which<br /> takes a reference to the embedded struct device.<br /> <br /> Remove the adapter from the IDR before tearing it down during<br /> deregistration (and on registration failure) to make sure its resources<br /> are not accessed after having been freed (e.g. the device name).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> svcrdma: wake sq waiters when the transport closes<br /> <br /> Threads parked in svc_rdma_sq_wait() on sc_sq_ticket_wait or<br /> sc_send_wait can hang indefinitely in TASK_UNINTERRUPTIBLE state<br /> across transport teardown, pinning svc_xprt references and<br /> blocking svc_rdma_free().<br /> <br /> The close path sets XPT_CLOSE before invoking xpo_detach and both<br /> wait_event predicates include an XPT_CLOSE term, but the<br /> predicates are re-evaluated only on wakeup. sc_sq_ticket_wait has<br /> no completion-driven wake path; it is advanced solely by the<br /> chained ticket handoff inside svc_rdma_sq_wait() itself. Without<br /> an explicit wake at close, parked threads never observe<br /> XPT_CLOSE, hold their svc_xprt_get reference forever, and<br /> svc_rdma_free() blocks on xpt_ref dropping to zero.<br /> <br /> Two close entry points reach this transport. Local teardown runs<br /> svc_rdma_detach() from svc_handle_xprt() -&gt; svc_delete_xprt() -&gt;<br /> xpo_detach() on a worker thread. A remote disconnect arrives at<br /> svc_rdma_cma_handler(), which calls svc_xprt_deferred_close():<br /> that sets XPT_CLOSE and enqueues the transport but does not<br /> access either RDMA waitqueue, so a worker already parked in<br /> svc_rdma_sq_wait() never re-evaluates its predicate. With every<br /> worker parked on this transport, no thread is available to run<br /> the local teardown either, and the wake site there is<br /> unreachable.<br /> <br /> Introduce svc_rdma_xprt_deferred_close(), a thin svcrdma wrapper<br /> that calls svc_xprt_deferred_close() and then wakes both<br /> sc_sq_ticket_wait and sc_send_wait. Convert the svcrdma producers<br /> that called svc_xprt_deferred_close() directly:<br /> svc_rdma_cma_handler(), qp_event_handler(),<br /> svc_rdma_post_send_err(), svc_rdma_wc_send(), the sendto drop<br /> path, the rw completion error paths, and the recvfrom flush and<br /> read-list error paths.<br /> <br /> Wake both waitqueues from svc_rdma_detach() as well. The<br /> synchronous svc_xprt_close() path (backchannel ENOTCONN, device<br /> removal via svc_rdma_xprt_done) reaches detach without flowing<br /> through svc_xprt_deferred_close() and therefore does not invoke<br /> the new helper.<br /> <br /> [ cel: add svc_rdma_xprt_deferred_close() to complete the fix ]