Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust: block: fix GenDisk cleanup paths<br /> <br /> GenDiskBuilder::build() still has fallible work after<br /> __blk_mq_alloc_disk(), but its error path only recovers the<br /> foreign queue data. That leaks the temporary gendisk and<br /> request_queue until later teardown. If the caller moved the last<br /> Arc into build(), the leaked queue can retain blk-mq<br /> state after the tag set is dropped.<br /> <br /> Fix the pre-registration failure path by dropping the temporary<br /> gendisk reference with put_disk() before recovering queue_data,<br /> so disk_release() can tear down the owned queue.<br /> <br /> Also pair GenDisk::drop() with put_disk() after del_gendisk().<br /> Once a Rust GenDisk has been added with device_add_disk(),<br /> del_gendisk() only unregisters it; the final gendisk reference<br /> still has to be dropped to complete the release path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: NFIT: core: Fix possible NULL pointer dereference<br /> <br /> After commit 9b311b7313d6 ("ACPI: NFIT: Install Notify() handler before<br /> getting NFIT table"), acpi_nfit_probe() installs an ACPI notify handler<br /> for the NFIT device before checking the presence of the NFIT table. If<br /> that table is not there, 0 is returned without allocating the acpi_desc<br /> object and setting the driver data pointer of the NFIT device. If the<br /> platform firmware triggers an NFIT_NOTIFY_UC_MEMORY_ERROR notification<br /> on the NFIT device at that point, acpi_nfit_uc_error_notify() will<br /> dereference a NULL pointer.<br /> <br /> Prevent that from occurring by adding an acpi_desc check against NULL<br /> to acpi_nfit_uc_error_notify().

*** 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 /> 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)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup<br /> <br /> If acpi_nfit_init() fails after adding the acpi_desc object to the<br /> acpi_descs list, that object is never removed from that list because<br /> the acpi_nfit_shutdown() devm action is not added for the NFIT device<br /> in that case. Next, the acpi_nfit_init() failure causes<br /> acpi_nfit_probe() to fail, the acpi_desc object is freed, and a<br /> dangling pointer is left behind in the acpi_descs. Any subsequent<br /> ACPI Machine Check Exception will trigger nfit_handle_mce() which<br /> iterates over acpi_descs and so a use-after-free will occur.<br /> <br /> Moreover, if acpi_nfit_probe() returns 0 after installing a notify<br /> handler for the NFIT device and without allocating the acpi_desc<br /> object and setting the NFIT device&amp;#39;s driver data pointer, the<br /> acpi_desc object will be allocated by acpi_nfit_update_notify()<br /> and acpi_nfit_init() will be called to initialize it. Regardless<br /> of whether or not acpi_nfit_init() fails in that case, the<br /> acpi_nfit_shutdown() devm action is not added for the NFIT device<br /> and acpi_desc is never removed from the acpi_descs list. If the<br /> acpi_desc object is freed subsequently on driver removal, any<br /> subsequent ACPI MCE will lead to a use-after-free like in the<br /> previous case.<br /> <br /> To address the first issue mentioned above, make acpi_nfit_probe()<br /> call acpi_nfit_shutdown() directly on acpi_nfit_init() failures and<br /> to address the other one, add a remove callback to the driver and<br /> make it call acpi_nfit_shutdown(). Also, since it is now possible to<br /> pass NULL to acpi_nfit_shutdown() or the acpi_desc object passed to it<br /> may not have been initialized, add checks against NULL for acpi_desc and<br /> its nvdimm_bus field to that function and make acpi_nfit_unregister()<br /> clear the latter after unregistering the NVDIMM bus.

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

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

*** 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 /> 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.