Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/zcrypt: Close speculative mem read possibility<br /> <br /> The domain value is extracted from a given CCA or EP11 ioctl struct<br /> when a CPRB is about to be sent. Thus this is a user controlled value.<br /> Under some special conditions (custom device node used, administrative<br /> load) this value is used as an array index after bounds checking, but<br /> without speculation barrier.<br /> <br /> Add the missing array_index_nospec() call to prevent speculative<br /> execution where this domain value is used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: Supply the overflow slot size in BPOS, not the whole bin BO size<br /> <br /> vc4_overflow_mem_work() points BPOA at a 512KB slot inside the 16MB<br /> binner BO, but writes the size of the whole BO to BPOS. On every binner<br /> out-of-memory event the PTB is therefore authorized to write tile lists<br /> across all the other slots (which may hold the tile state, tile alloc and<br /> overflow memory of in-flight jobs) and, for any slot but the first, past<br /> the end of the binner BO into unrelated CMA memory.<br /> <br /> Since CMA pages are recycled into page cache and user allocations, this<br /> is arbitrary memory corruption by GPU DMA. In practice it shows up as GPU<br /> hangs with corrupted control list pointers, userspace heap corruption, a<br /> GPU that stays permanently wedged after the first hang, and occasional<br /> full system crashes, whenever a job overflows the initial binner slot.<br /> <br /> The bug dates back to the conversion from a dedicated overflow BO (where<br /> writing the full BO size was correct) to the slotted binner BO.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: peak_usb: validate uCAN receive record lengths<br /> <br /> pcan_usb_fd_decode_buf() walks uCAN records packed in one USB<br /> receive buffer.<br /> <br /> Require each record to contain the fixed header for its type, and verify<br /> CAN payload bytes before copying them into the skb.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error<br /> <br /> In peak_usb_start(), each RX URB transfer buffer is allocated with kmalloc()<br /> and the URB is flagged URB_FREE_BUFFER so that the final usb_free_urb() also<br /> frees the transfer buffer.<br /> <br /> If usb_submit_urb() fails, the error path frees the buffer explicitly with<br /> kfree(buf) and then calls usb_free_urb(urb). Because URB_FREE_BUFFER is set,<br /> usb_free_urb() -&gt; urb_destroy() frees the same buffer a second time, a double<br /> free of the transfer buffer.<br /> <br /> BUG: KASAN: double-free in usb_free_urb.part.0+0x91/0xb0<br /> Free of addr ffff8881069ccb80 by task trigger.sh/285<br /> <br /> Call Trace:<br /> kfree+0x113/0x3c0<br /> usb_free_urb.part.0+0x91/0xb0<br /> <br /> Drop the redundant kfree(buf); usb_free_urb() already releases the transfer<br /> buffer. This mirrors commit 03819abbeb11 ("net: usb: lan78xx: Fix double free<br /> issue with interrupt buffer allocation").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: peak_usb: add bounds check for USB channel index<br /> <br /> The channel control index ctrl_idx is derived from rx-&gt;len which comes<br /> directly from a device USB payload. The mask 0x0f allows values 0-15, but<br /> the array size of usb_if-&gt;dev[] is only 2. Values 2-15 cause heap<br /> out-of-bounds read, eventually causing kernel panic in the IRQ context.<br /> <br /> Add bounds checking for ctrl_idx before the array access in both<br /> pcan_usb_pro_handle_canmsg() and pcan_usb_pro_handle_error().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents<br /> <br /> The wait and bulk receive paths walk variable-length commands from a<br /> USB buffer. A nonzero command shorter than CMD_HEADER_LEN can still be<br /> dispatched, and the wait path copies a matching command into a fixed<br /> caller-owned struct kvaser_cmd using the device-provided length.<br /> <br /> Reject nonzero commands that do not contain the fixed header or that<br /> extend beyond the current USB buffer item. In the wait path, also reject<br /> a matching command that exceeds the destination before copying it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB resubmit failure<br /> <br /> es58x_read_bulk_callback() resubmits the RX URB after processing a received<br /> packet. If the resubmit succeeds, the URB remains anchored and will be<br /> handled by the normal RX path or by teardown.<br /> <br /> However, if usb_submit_urb() fails, the callback unanchors the URB and then<br /> returns directly. This skips the existing free_urb path, so the coherent<br /> transfer buffer allocated with usb_alloc_coherent() is not released.<br /> <br /> Reuse the existing free_urb path after a resubmit failure so that the RX<br /> coherent buffer is freed before leaving the callback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: ems_usb: validate CPC message lengths<br /> <br /> ems_usb_read_bulk_callback() walks CPC messages packed in one USB<br /> receive buffer.<br /> <br /> Check that each declared message fits in the URB payload. Also require the<br /> type-specific payload to cover the fields used by the CAN, state, error and<br /> overrun handlers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: imx: Cancel hrtimer before clearing slave pointer<br /> <br /> In i2c_imx_unreg_slave(), the slave pointer is set to NULL after<br /> disabling interrupts. However, a pending interrupt might already<br /> have started the hrtimer (i2c_imx_slave_timeout) before the pointer<br /> was cleared. If the hrtimer fires after i2c_imx-&gt;slave is set to<br /> NULL, the timer callback i2c_imx_slave_finish_op() will call<br /> i2c_imx_slave_event() with a NULL slave pointer, which results in a<br /> use-after-free / NULL pointer dereference.<br /> <br /> Fix by canceling the hrtimer and waiting for it to complete after<br /> disabling interrupts, before clearing the slave pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock<br /> <br /> Fix a severe AB/BA deadlock between the Common Clock Framework (CCF)<br /> and the I2C adapter lock, which triggers when an I2C-controlled clock<br /> generator client (like the Si5351) is registered or modified under the CCF.<br /> <br /> During an i2c client clock (generator) frequency change, the CCF acquires its global<br /> &amp;#39;prepare_lock&amp;#39; mutex and the driver calls i2c_transfer() to update the client&amp;#39;s<br /> chip registers, stalling for the adapter&amp;#39;s I2C bus lock.<br /> <br /> Concurrently, an independent, parallel transfer on the same bus (e.g., a GPIO<br /> expander handling LEDs) can hold the I2C adapter lock. Inside this parallel<br /> transfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the host<br /> controller&amp;#39;s input clock to calculate bus timings. This call attempts to acquire<br /> the blocked CCF &amp;#39;prepare_lock&amp;#39;, creating a circular dependency that freezes<br /> the system.<br /> <br /> The jz4780 host controller clock itself is static and never changes at runtime.<br /> <br /> However, calling clk_get_rate() inside the active transfer path introduces<br /> an unnecessary dependency on the CCF internal locks.<br /> <br /> Eliminate this synchronous clk_get_rate() call from the active transfer<br /> path by caching the static host peripheral clock rate once - inside the private<br /> jz4780_i2c structure during jz4780_i2c_probe(). Update jz4780_i2c_set_speed()<br /> to use this cached value, safely decoupling active I2C transactions from the<br /> CCF internal locks without any risk of stale timings.<br /> <br /> Assisted-by web based Google AI (pinpointing the bug and writing the message).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: imx: 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 /> drm/amdkfd: hold event_mutex while checkpointing CRIU events<br /> <br /> kfd_criu_checkpoint_events() counts the entries in p-&gt;event_idr via<br /> kfd_get_num_events(), allocates an array sized to that count, and then<br /> walks the same IDR to fill it. Neither the count nor the walk holds<br /> p-&gt;event_mutex.<br /> <br /> The CRIU checkpoint caller holds only p-&gt;mutex. Event create and destroy<br /> (kfd_event_create()/kfd_event_destroy()) take p-&gt;event_mutex and do not<br /> take p-&gt;mutex, so a second thread in the same process can insert or remove<br /> events between the count and the walk. If an event is inserted, the walk<br /> iterates more entries than were counted and writes past the end of the<br /> ev_privs allocation; if an event is removed, the walk dereferences an<br /> entry that is being freed.<br /> <br /> Hold p-&gt;event_mutex across the count and the walk so both observe a<br /> consistent view of p-&gt;event_idr. The lock is released before<br /> copy_to_user(), which only touches the local buffer. The caller already<br /> holds p-&gt;mutex and the create/destroy paths never take p-&gt;mutex, so the<br /> p-&gt;mutex -&gt; p-&gt;event_mutex order is not inverted and no deadlock is<br /> introduced.<br /> <br /> (cherry picked from commit ff57e223ab105795b05d3ef3f3c35a5a441bcbaa)