Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: CPPC: Suppress UBSAN warning caused by field misuse<br /> <br /> The definition of reg-&gt;access_width changes depending on the<br /> reg-&gt;space_id type. Type ACPI_ADR_SPACE_PLATFORM_COMM uses<br /> access_width to indicate the PCC region, which can result in a UBSAN<br /> if the value is greater than 4.<br /> <br /> For example:<br /> <br /> UBSAN: shift-out-of-bounds in drivers/acpi/cppc_acpi.c:1090:9<br /> shift exponent 32 is too large for 32-bit type &amp;#39;int&amp;#39;<br /> CPU: 61 UID: 0 PID: 1220 Comm: (udev-worker) Not tainted 7.0.10-201.fc44.aarch64 #1 PREEMPT(lazy)<br /> Hardware name: To be filled by O.E.M.<br /> Call trace:<br /> ...(trimming)<br /> ubsan_epilogue+0x10/0x48<br /> __ubsan_handle_shift_out_of_bounds+0xdc/0x1e0<br /> cpc_write+0x4d0/0x670<br /> cppc_set_perf+0x18c/0x490<br /> cppc_cpufreq_cpu_init+0x1c8/0x380 [cppc_cpufreq]<br /> ... (trimming)<br /> <br /> Lets fix this by validating the region type, as well as whether<br /> access_width has a value. Then since we are returning bit_width<br /> directly for ACPI_ADR_SPACE_PLATFORM_COMM, drop the code correcting<br /> the size.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Unconditionally recompute CR8 intercept on PPR update<br /> <br /> The TPR_THRESHOLD field in the VMCS is used by VMX to induce VM exits<br /> when the guest&amp;#39;s virtual TPR falls under the specified threshold,<br /> allowing KVM to inject previously masked interrupts.<br /> <br /> KVM handles these VM exits in handle_tpr_below_threshold().<br /> Commit eb90f3417a0c ("KVM: vmx: speed up TPR below threshold vmexits")<br /> optimized this function by calling apic_update_ppr() instead of raising<br /> KVM_REQ_EVENT. apic_update_ppr() then raises KVM_REQ_EVENT if there is<br /> a pending, deliverable interrupt.<br /> <br /> However, if there are no new interrupts pending, apic_update_ppr() does<br /> not issue the request. Thus, kvm_lapic_update_cr8_intercept() and<br /> vmx_update_cr8_intercept() are not called before VM entry, which results<br /> in a high, stale TPR_THRESHOLD. This is problematic due to the following<br /> sentence in 28.2.1.1 "VM-Execution Control Fields" in the SDM:<br /> <br /> The following check is performed if the “use TPR shadow” VM-execution<br /> control is 1 and the “virtualize APIC accesses” and “virtual-interrupt<br /> delivery” VM-execution controls are both 0: the value of bits 3:0 of<br /> the TPR threshold VM-execution control field should not be greater<br /> than the value of bits 7:4 of VTPR.<br /> <br /> This error condition is typically not observed when KVM runs on a bare<br /> metal system because modern processors support APICv, which enables<br /> virtual-interrupt delivery, and which KVM uses when possible. This<br /> causes the processor to no longer generate TPR-below-threshold exits<br /> and to no longer check TPR_THRESHOLD on entry. However, when running<br /> on older platforms, or under nested virtualization on a hypervisor that<br /> does not support virtual-interrupt delivery and enforces this check<br /> (like Hyper-V) this can cause a VM entry failure with hardware error<br /> 0x7, as seen in [1].<br /> <br /> Call kvm_lapic_update_cr8_intercept() if apic_update_ppr() does not<br /> find a deliverable interrupt (and thus does not raise KVM_REQ_EVENT).<br /> Remove calls to kvm_lapic_update_cr8_intercept() on paths that end up in<br /> apic_update_ppr(), as they now become redundant. This ensures that any<br /> path that updates the guest&amp;#39;s PPR also figures out if KVM needs to wait<br /> for a TPR change (using TPR_THRESHOLD on VMX or CR8 intercepts on SVM).

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducció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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: temperature: tmp006: use devm_iio_trigger_register<br /> <br /> tmp006_probe() allocates the DRDY trigger with devm_iio_trigger_alloc()<br /> but registers it with plain iio_trigger_register(). The driver has no<br /> .remove() callback, so on module unload the trigger stays in the global<br /> trigger list while its memory is freed by devm, leaving a dangling<br /> entry.<br /> <br /> Switch to devm_iio_trigger_register() so the registration is undone in<br /> the same devm scope as the allocation.