Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> userfaultfd: gate must_wait writability check on pte_present()<br /> <br /> userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE<br /> without taking the page table lock and then apply pte_write() /<br /> huge_pte_write() to it. Those accessors decode bits from the present<br /> encoding only; on a swap or migration entry they read the offset bits that<br /> happen to share the same position and return an undefined result.<br /> <br /> The intent of the check is "is this fault still WP-blocked?". A<br /> non-marker swap entry means the page is in transit -- the userfault<br /> context the original fault delivered against is no longer the same, and<br /> the swap-in or migration completion path will re-deliver a fresh fault if<br /> userspace still needs to handle it. Worst case under the current code the<br /> garbage write bit says "wait", and the thread stays asleep until a<br /> UFFDIO_WAKE that may never arrive.<br /> <br /> Gate the writability check on pte_present() so the lockless re-check only<br /> inspects present-PTE bits when the entry is actually present. The<br /> non-present, non-marker case returns "don&amp;#39;t wait" and lets the fault path<br /> retry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix MLE defragmentation<br /> <br /> If either reconf or EPCS multi-link element (MLE) is contained in<br /> a non-transmitted profile, the defragmentation routine is called<br /> with a pointer to the defragmented copy, but the original elements.<br /> <br /> This is incorrect for two reasons:<br /> - if the original defragmentation was needed, it will not find the<br /> correct data<br /> - if the original frame is at a higher address, the parsing will<br /> potentially overrun the heap data (though given the layout of<br /> the buffers, only into the new defragmentation buffer, and then<br /> it has to stop and fail once that&amp;#39;s filled with copied data.<br /> <br /> Fix it by tracking the container along with the pointer and in<br /> doing so also unify the two almost identical defragmentation<br /> routines.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/vce1: Fix VCE 1 firmware size and offsets<br /> <br /> The VCPU BO contains the actual FW at an offset, but<br /> it was not calculated into the VCPU BO size.<br /> Subtract this from the FW size to make sure there is<br /> no out of bounds access.<br /> <br /> Make sure the stack and data offsets are aligned to<br /> the 32K TLB size.<br /> <br /> Check that the FW microcode actually fits in the<br /> space that is reserved for it.<br /> <br /> (cherry picked from commit c16fe59f622a080fc457a57b3e8f14c780699449)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/gsc: Fix double-free of managed BO in error path<br /> <br /> The error path in xe_gsc_init_post_hwconfig() explicitly frees a BO<br /> allocated with xe_managed_bo_create_pin_map() via<br /> xe_bo_unpin_map_no_vm(). Since the managed BO already has a devm<br /> cleanup action registered, this causes a double-free when devm<br /> unwinds during probe failure.<br /> <br /> Remove the explicit free and let devm handle it, consistent with<br /> all other xe_managed_bo_create_pin_map() callers.<br /> <br /> (cherry picked from commit 71d61e3e299a17139e47f980a4d6f425b2c59bf7)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ad_sigma_delta: fix CS held asserted and state leaks<br /> <br /> In ad_sigma_delta_single_conversion(), set_mode(AD_SD_MODE_IDLE) and<br /> disable_one() were called from the out: block while keep_cs_asserted<br /> was still true. This caused any SPI transfer issued by those callbacks<br /> to carry cs_change=1, leaving CS permanently asserted after the<br /> conversion. Fix by moving both calls into the out_unlock: block, after<br /> keep_cs_asserted is cleared, matching the pattern already used in<br /> ad_sd_calibrate().<br /> <br /> In the error path of ad_sd_buffer_postenable(), if an operation fails<br /> after set_mode(AD_SD_MODE_CONTINUOUS) has already succeeded (e.g.<br /> spi_offload_trigger_enable()), the device is left in continuous<br /> conversion mode with CS physically asserted. Additionally,<br /> bus_locked remaining true after spi_bus_unlock() causes subsequent<br /> SPI operations to call spi_sync_locked() without the bus lock actually<br /> held, allowing concurrent SPI access.<br /> <br /> Fix the error path by clearing keep_cs_asserted first, then calling<br /> set_mode(AD_SD_MODE_IDLE) to revert the device mode and deassert CS,<br /> then clearing bus_locked before releasing the bus.<br /> <br /> For devices that implement neither set_mode nor disable_one (such as<br /> MAX11205, which has no physical CS pin), no SPI transfer is issued<br /> during cleanup and the cs_change flag has no effect on any physical<br /> line.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ad_sigma_delta: fix clear_pending_event for registerless devices<br /> <br /> ad_sigma_delta_clear_pending_event() falls through to the status register<br /> read path for devices with has_registers = false and no rdy_gpiod. For<br /> such devices, ad_sd_read_reg() skips the address byte entirely and clocks<br /> raw MISO bytes with no address phase — making it byte-for-byte identical<br /> to reading conversion data. If a pending conversion result is present,<br /> this partially consumes it and corrupts the data stream for the subsequent<br /> ad_sd_read_reg() call in ad_sigma_delta_single_conversion().<br /> <br /> Furthermore, with num_resetclks = 0 on these devices, data_read_len<br /> evaluates to 0. If the clocked byte has bit 7 clear, pending_event is set<br /> and the code attempts memset(data + 2, 0xff, 0 - 1), overflowing to<br /> SIZE_MAX and corrupting the heap.<br /> <br /> Fix by returning 0 immediately when neither rdy_gpiod nor has_registers<br /> is set. This is safe for all current registerless devices: ad7191 and<br /> ad7780 (with powerdown GPIO) are reset between conversions by CS<br /> deassertion, so there is no stale result to drain; ad7780 (without<br /> powerdown GPIO) and max11205 are continuously-converting and cycle ~DRDY<br /> at the output data rate regardless of whether the previous result was<br /> read, so the next falling edge fires naturally.<br /> <br /> A future registerless device that holds ~DRDY asserted until data is read<br /> would be broken by this early return and would require either<br /> num_resetclks set or a rdy-gpio.<br /> <br /> The same heap corruption is reachable on any device with rdy_gpiod set<br /> but num_resetclks = 0: if the GPIO indicates a pending event, the drain<br /> path executes memset(data + 2, 0xff, 0 - 1) regardless of has_registers.<br /> Add an explicit data_read_len == 0 guard after the pending event check;<br /> the stale result is then consumed by the first ad_sd_read_reg() call in<br /> ad_sigma_delta_single_conversion().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error<br /> <br /> kxsd9_write_raw() takes a runtime PM reference with pm_runtime_get_sync()<br /> but returns -EINVAL directly when a scale with a non-zero integer part is<br /> requested, skipping the matching pm_runtime_put_autosuspend(). This leaks<br /> a runtime PM usage-counter reference on every such write, after which the<br /> device can no longer autosuspend.<br /> <br /> Set the error code and fall through to the existing put instead of<br /> returning early.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: accel: bmc150: clamp the device-reported FIFO frame count<br /> <br /> __bmc150_accel_fifo_flush() copies the number of samples the device<br /> reports in its hardware FIFO into an on-stack buffer<br /> <br /> u16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3];<br /> <br /> which is sized for at most BMC150_ACCEL_FIFO_LENGTH (32) samples. The<br /> frame count is read from the FIFO_STATUS register and only masked to its<br /> 7 valid bits:<br /> <br /> count = val &amp; 0x7F;<br /> <br /> so it can be 0..127. The only other limit applied to it is the optional<br /> caller-supplied sample budget:<br /> <br /> if (samples &amp;&amp; count &gt; samples)<br /> count = samples;<br /> <br /> which does not constrain count on the flush-all path (samples == 0), and<br /> leaves it well above 32 whenever samples is larger. count samples are<br /> then transferred into buffer[]:<br /> <br /> bmc150_accel_fifo_transfer(data, (u8 *)buffer, count);<br /> <br /> bmc150_accel_fifo_transfer() reads count * 6 bytes through regmap, so a<br /> malfunctioning, malicious or counterfeit accelerometer (or an attacker<br /> tampering with the I2C/SPI bus) that reports up to 127 frames writes up<br /> to 762 bytes into the 192-byte buffer: a stack out-of-bounds write of up<br /> to 570 bytes that clobbers the stack canary, saved registers and the<br /> return address.<br /> <br /> Clamp count to BMC150_ACCEL_FIFO_LENGTH, the number of samples buffer[]<br /> is sized for, before the transfer, mirroring the watermark clamp already<br /> done in bmc150_accel_set_watermark(). A well-formed flush reports at most<br /> BMC150_ACCEL_FIFO_LENGTH frames, so legitimate devices are unaffected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: function: rndis: add length check for header<br /> <br /> Add a length check for the rndis header in rndis_rm_hdr, to ensure that<br /> MessageType, MessageLength, DataOffset, and DataLength fields are<br /> present before they are accessed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: correct drop logic for malformed AMPDU frames<br /> <br /> The previous commit aims to fix issue caused by malformed AMPDU frames.<br /> But the drop logic fails to deal with the first AMPDU packet paired with<br /> certain range of sequence number, and leads to unexpected packet drop.<br /> It is more likely to encounter this failure when there are busy traffic<br /> during rekey process and could lead to disconnection from the AP.<br /> Fix this by adding a initial state judgement and only reset status<br /> during pairwise rekey.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/bugs: Enable IBPB flush on BPF JIT allocation<br /> <br /> Enable hardening against JIT spraying when Spectre-v2 mitigations are in<br /> use. Specifically, issue an IBPB flush on BPF JIT memory reuse. Skip<br /> enabling the IBPB flush if the BPF dispatcher is already using a retpoline<br /> sequence.<br /> <br /> This hardening applies only when BPF-JIT is in use. Guard the enabling<br /> under CONFIG_BPF_JIT so that bugs.c still builds with CONFIG_BPF_JIT=n.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Support for hardening against JIT spraying<br /> <br /> The BPF JIT allocator packs many small programs into larger executable<br /> allocations and reuses space within those allocations as programs are<br /> loaded and freed. When fresh code is written into space that a previous<br /> program occupied, an indirect jump into the new program can reuse a branch<br /> prediction left behind by the old one.<br /> <br /> Flush the indirect branch predictors before reusing JIT memory so that<br /> indirect jumps into a newly written program don&amp;#39;t reuse predictions from an<br /> old program that occupied the same space.<br /> <br /> Introduce bpf_arch_pred_flush_enabled static key and bpf_arch_pred_flush<br /> static call for flushing the branch predictors on JIT memory reuse.<br /> Architectures that need a flush, can update it to a predictor flush<br /> function. By default, its a NOP and does not emit any CALL.<br /> <br /> Allocations larger than a pack are not covered by this flush. That is safe<br /> because cBPF programs (the unprivileged attack surface) are bounded well<br /> below a pack size. Issue a warning if this assumption is ever violated<br /> while the flush is active.