Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: meson: amlogic-a4: fix deadlock issue<br /> <br /> Accessing the pinconf-pins sysfs node may deadlock.<br /> <br /> pinconf_pins_show() holds pctldev-&gt;mutex, and the platform driver<br /> calls pinctrl_find_gpio_range_from_pin(), which tries to acquire<br /> the same mutex again, leading to a deadlock.<br /> <br /> Use pinctrl_find_gpio_range_from_pin_nolock() to fix this issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix eswitch mode block underflow on IPsec acquire SA<br /> <br /> mlx5e_xfrm_add_state() handles acquire-flow temporary SAs by allocating<br /> software state and skipping hardware offload setup.<br /> <br /> That path jumps to the common success label before taking the eswitch mode<br /> block. After tunnel-mode validation was moved earlier, the common success<br /> label unconditionally calls mlx5_eswitch_unblock_mode(). For acquire SAs,<br /> this decrements esw-&gt;offloads.num_block_mode without a matching increment.<br /> <br /> Return directly after installing the acquire SA offload handle, so only the<br /> paths that successfully called mlx5_eswitch_block_mode() call the matching<br /> unblock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/handshake: Take a long-lived file reference at submit<br /> <br /> handshake_nl_accept_doit() needs the file pointer backing<br /> req-&gt;hr_sk-&gt;sk_socket to survive the window between<br /> handshake_req_next() and the subsequent FD_PREPARE() and get_file().<br /> The submit-side sock_hold() does not provide that. sk_refcnt keeps<br /> struct sock alive, but struct socket is owned by sock-&gt;file: when<br /> the consumer fputs the last file reference, sock_release() tears<br /> the socket down regardless of any sock_hold.<br /> <br /> Add an hr_file pointer to struct handshake_req and acquire an<br /> explicit reference on sock-&gt;file during handshake_req_submit().<br /> handshake_complete() and handshake_req_cancel() release the<br /> reference on the completion-bit-winning path.<br /> <br /> The submit error path must also release the file reference, but<br /> after rhashtable insertion a concurrent handshake_req_cancel() can<br /> discover the request and race the error path. Gate the error-path<br /> cleanup -- sk_destruct restoration, fput, and request destruction<br /> -- with test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED), the same<br /> serialization handshake_complete() and handshake_req_cancel()<br /> already use. When cancel has already claimed ownership, the submit<br /> error path returns without touching the request; socket teardown<br /> handles final destruction.<br /> <br /> The accept-side dereferences are not yet retargeted; that change<br /> comes in the next patch.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/hyperv: validate resolution_count and fix WIN8 fallback<br /> <br /> A SYNTHVID_RESOLUTION_RESPONSE with resolution_count &gt; 64 walks past<br /> the supported_resolution[SYNTHVID_MAX_RESOLUTION_COUNT] array in the<br /> parse loop. Bound resolution_count against the array size, folded<br /> into the existing zero-check.<br /> <br /> When the WIN10 resolution probe fails, the caller in<br /> hyperv_connect_vsp() left hv-&gt;screen_*_max / preferred_* unpopulated,<br /> which sets mode_config.max_width / max_height to 0 and makes<br /> drm_internal_framebuffer_create() reject every userspace framebuffer<br /> with -EINVAL. The pre-WIN10 branch had the same gap for<br /> preferred_width / preferred_height. Use a single post-probe fallback<br /> guarded by screen_width_max == 0 so both paths converge on the WIN8<br /> defaults.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit<br /> <br /> The struct pernet_operations docstring in include/net/net_namespace.h<br /> explicitly warns against blocking RCU primitives in .exit handlers:<br /> <br /> Exit methods using blocking RCU primitives, such as<br /> synchronize_rcu(), should be implemented via exit_batch.<br /> [...]<br /> Please, avoid synchronize_rcu() at all, where it&amp;#39;s possible.<br /> <br /> Note that a combination of pre_exit() and exit() can<br /> be used, since a synchronize_rcu() is guaranteed between<br /> the calls.<br /> <br /> xfrm_policy_fini() violates this: it calls synchronize_rcu() before<br /> freeing the policy_bydst hash tables (so no RCU reader is mid-<br /> traversal at free time), but runs from xfrm_net_ops.exit -- once per<br /> namespace -- so a cleanup_net() of N namespaces pays N full RCU<br /> grace periods serially.<br /> <br /> Use the documented pre_exit/exit split. Move the policy flush (and<br /> the workqueue drains it depends on) into a new .pre_exit handler;<br /> xfrm_policy_fini() then runs in .exit and frees the hash tables<br /> after the synchronize_rcu_expedited() that cleanup_net() guarantees<br /> between the two phases. Providing O(1) RCU grace periods per batch<br /> instead of O(N).<br /> <br /> Observed on Linux 6.18 with a workload doing unshare(CLONE_NEWNET)<br /> at ~13/sec sustained: cleanup_net() and the netns_wq rescuer kthread<br /> both stuck in xfrm_policy_fini()&amp;#39;s synchronize_rcu(), &gt;300k struct<br /> net accumulated in the cleanup queue, Percpu in /proc/meminfo climbed<br /> to 130+ GB on 256-CPU hosts, and memcg OOMs followed. setup_net and<br /> __put_net counts were balanced, ruling out a refcount leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: tsconfig: fix missing ethnl_ops_complete()<br /> <br /> tsconfig_prepare_data() calls ethnl_ops_begin(), we need to call<br /> ethnl_ops_complete() before returning the error.

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