Vulnerabilities

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 ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Don&amp;#39;t leak PFN when kvm_translate_vncr() races MMU notifier<br /> <br /> In the case that kvm_translate_vncr() races with an MMU notifier the<br /> early return does not release a reference on the faulted in PFN. Add<br /> the necessary call to kvm_release_faultin_page() for the unused PFN.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: guest_memfd: Treat memslot binding offset+size as unsigned values<br /> <br /> When binding a memslot to a guest_memfd file, treat the offset and size as<br /> unsigned values to fix a bug where the sum of the two can result in a false<br /> negative when checking for overflow against the size of the file. Passing<br /> unsigned values also avoids relying on somewhat obscure checks in other<br /> flows for safety, and tracks the offset and size as they are intended to be<br /> tracked, as unsigned values.<br /> <br /> On 64-bit kernels, the number of pages a memslot contains and thus the size<br /> (and offset) of its guest_memfd binding are unsigned 64-bit values. Taking<br /> the offset+size as an loff_t instead of a uoff_t inadvertently converts<br /> the unsigned value to a signed value if the offset and/or size is massive.<br /> <br /> Locally storing the offset and size as signed values is benign in and of<br /> itself (though even that is *extremely* difficult to discern), but<br /> operating on their sum is not.<br /> <br /> For the offset, KVM explicitly checks against a negative value, which might<br /> seem like a bug as KVM could incorrectly reject a legitimate binding, but<br /> that&amp;#39;s not actually the case as KVM_CREATE_GUEST_MEMFD takes a signed value<br /> for its size, i.e. a would-be-negative offset is also greater than the<br /> maximum possible size of any guest_memfd file.<br /> <br /> Regarding the size, while KVM lacks an explicit check for a negative value,<br /> i.e. seemingly has a flawed overflow check, KVM restricts the number of<br /> pages in a single memslot to the largest positive signed 32-bit value:<br /> <br /> if (id memory_size &gt;&gt; PAGE_SHIFT) &gt; KVM_MEM_MAX_NR_PAGES)<br /> return -EINVAL;<br /> <br /> and so that maximum "size" will ever be is 0x7fffffff000.<br /> <br /> The sum of the two is, however, problematic. While the size is restricted<br /> by KVM&amp;#39;s memslot logic, the offset is not, i.e. the offset is completely<br /> unchecked until the "offset + size &gt; i_size_read(inode)" check. If the<br /> offset is the (nearly) largest possible _positive_ value, then adding size<br /> to the offset can result in a signed, negative 64-bit value. When compared<br /> against the size of the file (guaranteed to be positive), the negative sum<br /> is always smaller, and KVM incorrectly allows the absurd offset.<br /> <br /> Opportunistically add missing includes in kvm_mm.h (instead of relying on<br /> its parents).