Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio_ccw: Free all memory if cp_init() fails<br /> <br /> The routine cp_free() is called to unpin/free any memory once an I/O<br /> is completed successfully, or if cp_prefetch() fails. But if cp_init()<br /> fails, and cp-&gt;initialized is not enabled, the same routine cannot be<br /> used to free all the memory.<br /> <br /> An attempt to address this exists in ccwchain_handle_ccw(), where a<br /> single call to ccwchain_free() is made for the currently-processed<br /> CCW segment. But this will leak other segments (created as a result<br /> of a Transfer in Channel) that had been allocated as part of the same<br /> channel program.<br /> <br /> Address this by performing the cleanup outside of the recursive<br /> ccwchain_handle_ccw()/ccwchain_loop_tic() logic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: atmel-mci: Fix use-after-free in atmci_remove due to race condition<br /> <br /> In atmci_probe, &amp;host-&gt;bh_work is bound with atmci_work_func, and<br /> atmci_interrupt, atmci_timeout_timer and atmci_dma_complete can all<br /> queue this work on system_bh_wq.<br /> <br /> If we remove the module, atmci_remove makes cleanup and the memory<br /> allocated for host with devm_kzalloc() is released after the remove<br /> callback returns, while the work mentioned above may still be pending<br /> or running. The sequence of operations that may lead to a UAF bug is<br /> as follows:<br /> <br /> CPU0 CPU1<br /> <br /> | atmci_interrupt<br /> | queue_work(system_bh_wq,<br /> | &amp;host-&gt;bh_work)<br /> atmci_remove |<br /> atmci_cleanup_slot(...) |<br /> atmci_writel(host, ATMCI_IDR, ~0UL) |<br /> timer_delete_sync(&amp;host-&gt;timer) |<br /> dma_release_channel(host-&gt;dma.chan) |<br /> free_irq(platform_get_irq(pdev, 0), host) |<br /> | atmci_work_func<br /> | // use host<br /> // devm resources released after |<br /> // remove returns, host is freed |<br /> | // use host (use-after-free)<br /> <br /> Fix it by canceling the work after all the sources that can schedule<br /> it (IRQ handler, timeout timer and DMA completion callback) have been<br /> stopped, and before proceeding with the remaining cleanup in<br /> atmci_remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: fix OOB read in decode_watchers() via missing bounds check<br /> <br /> ceph_start_decoding() validates that struct_len bytes remain in the<br /> buffer after the encoding header, but accepts struct_len=0 as valid:<br /> ceph_decode_need(p, end, 0, bad) always passes. When a malicious or<br /> compromised OSD sends an obj_list_watch_response_t reply with<br /> struct_len=0, ceph_start_decoding() returns success with p == end,<br /> leaving zero bytes guaranteed for subsequent reads.<br /> <br /> The immediately following ceph_decode_32(p) in decode_watchers() has<br /> no preceding bounds check. With p == end this is a 4-byte read past<br /> the validated buffer boundary. The garbage value is then passed<br /> directly to kzalloc_objs() as the watcher count.<br /> <br /> The sibling function decode_watcher() already uses the safe variants<br /> (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32)<br /> after its own ceph_start_decoding() call. decode_watchers() is the<br /> only site that uses the bare variant, confirming an oversight.<br /> <br /> Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end,<br /> *num_watchers, bad), consistent with the established pattern.<br /> <br /> Attacker model: a malicious or compromised OSD in a multi-tenant Ceph<br /> deployment (e.g. cloud) can trigger this against any kernel client<br /> that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges<br /> beyond OSD session establishment.<br /> <br /> [ idryomov: trim changelog ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: Avoid using invalid osd indices from primary_temp<br /> <br /> A corrupted osdmap received from a Ceph monitor or OSD may contain osd<br /> indices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts<br /> that don&amp;#39;t exist, i.e., that are greater than max_osd or smaller than<br /> CEPH_HOMELESS_OSD (-1). These indices are used to create the up and<br /> acting set in ceph_pg_to_up_acting_osds(), called from calc_target().<br /> While most of these osd indices are checked, the one from primary_temp<br /> is not. Subsequently, this may lead to calc_target() returning this<br /> (potentially invalid) index as target osd for a (linger) request.<br /> Because the osd_state, osd_weight, and osd_addr arrays only contain<br /> max_osd entries (with indices 0 to max_osd -1), this leads to<br /> out-of-bounds accesses when trying to read values from these arrays.<br /> <br /> This patch fixes the issue by adding a check to get_temp_osds(), so that<br /> only valid osd indices from primary_temp are used, and it falls back to<br /> using the primary from pg_temp or the up set if it is invalid.<br /> <br /> [ idryomov: changelog ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: sur40 - fix input device registration ordering<br /> <br /> In sur40_probe(), input_register_device() was previously called early before<br /> the V4L2 video device and vb2_queue components were fully initialized. If<br /> userspace opened the input device immediately upon registration, sur40_open()<br /> would trigger and start the sur40_poll() worker thread. This worker thread<br /> invokes sur40_process_video() and accesses the uninitialized vb2_queue<br /> structure, leading to a data race and potential system crash.<br /> <br /> Furthermore, if V4L2 or video registration failed after input_register_device()<br /> succeeded, the error path fell through to calling input_free_device() on a<br /> successfully registered device instead of input_unregister_device(), corrupting<br /> input core state.<br /> <br /> Move input_register_device() to the very end of sur40_probe(). This ensures<br /> the V4L2 and video queue structures are fully initialized before polling can<br /> start, and naturally resolves the error path bug since input_free_device()<br /> is now only called when input registration has not yet occurred.<br /> <br /> To maintain strict LIFO (Last-In, First-Out) teardown ordering, also move<br /> input_unregister_device() to the very beginning of sur40_disconnect(). This<br /> guarantees that the input polling worker thread is stopped before V4L2<br /> video components or control handlers are unregistered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> openrisc: signal: do not restore privileged SR bits on sigreturn<br /> <br /> restore_sigcontext() copies the whole supervision register (SR) from the<br /> signal frame and only clears SPR_SR_SM before the value is reloaded into<br /> the hardware SR (through ESR and l.rfe) on the return to user space. All<br /> other SR bits are left under user control.<br /> <br /> An unprivileged task can thus return from a signal handler through a<br /> crafted sigframe that clears SPR_SR_DME. With the data MMU disabled the<br /> CPU performs no translation or protection on data accesses, so the task<br /> gains read and write access to arbitrary physical memory, a local<br /> privilege escalation. SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH<br /> and the cache-enable bits are exposed the same way. The ptrace GPR regset<br /> already refuses any change to SR for exactly this reason.<br /> <br /> Restore only the arithmetic flag bits (F, CY, OV) from the signal frame<br /> and take every privileged control bit from the SR the kernel saved on<br /> signal entry.<br /> <br /> Verified with qemu-system-or1k -M or1k-sim: before this change an<br /> unprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to<br /> physical address 0x03000000 (beyond the kernel&amp;#39;s mem=32M); afterwards the<br /> same PoC receives SIGSEGV and physical memory is unchanged.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio_ccw: Implement a crw lock<br /> <br /> Unlike the channel_program struct, which covers synchronous I/O<br /> submissions and asynchronous interrupts, the CRW region relies<br /> exclusively on asynchronous events coming from hardware.<br /> <br /> Implement a lock to manage the list of those payloads, to ensure<br /> they are read cohesively.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio_ccw: Selectively expand io_mutex<br /> <br /> The io_mutex was defined to serialize the io_regions, but then has<br /> also sort of been associated with the I/O themselves because of<br /> the close relationship they share.<br /> <br /> With the handful of races that are possible, the choices are either to:<br /> A) expand the scope of io_mutex to close these remaining windows, or<br /> B) reduce the scope of io_mutex to just io_region, and introduce a new<br /> lock mechanism for the remaining I/O resources<br /> <br /> This patch implements A, since B brings with it a lot more interactions<br /> that would need to be tracked and kept in a correct hierarchy. It also<br /> takes advantage of the workqueue element for cp_free() that now gets<br /> called out of fsm_notoper(), which could be invoked out of an interrupt<br /> context and thus cannot acquire a mutex itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio_ccw: Move cp cleanup out of not operational<br /> <br /> The fsm_notoper() routine is called when the device has been<br /> lost, and is (by definition) no longer operational. Since this<br /> can happen asynchronously from the normal behavior of the<br /> driver, the cleanup may happen when holding other locks<br /> in the calling sequence (notably, the cio subchannel lock).<br /> <br /> Push the cleanup of the private-&gt;cp resources to a workqueue,<br /> where it can be done out from under that lock sequence and<br /> a future patch can safely manage the locking requirements.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio_ccw: Fix out of bounds check on CCW array<br /> <br /> The routine ccwchain_calc_length() counts the number of channel<br /> command words (CCWs) that are chained together in a single channel<br /> program, and rejects anything larger than CCWCHAIN_LEN_MAX (256) CCWs.<br /> <br /> The loop itself is "do..while (count

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio_ccw: Ensure first IDAW remains constant<br /> <br /> The first IDAW in a list does not need to be on a 2K/4K boundary<br /> like all others, and so is read separately to accurately calculate<br /> the size of the buffer needed to read the full IDAL.<br /> <br /> Verify that the address found in the first IDAW is unchanged between<br /> reads, to ensure a consistent set of IDAWs being worked with.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio_ccw: Ensure index for read/write regions are within range<br /> <br /> The introduction of the capability chain rightly clamped the<br /> region indexes to the range of the capabilities itself, but<br /> neglected to do so for the existing read/write regions which<br /> should also be enforced.