Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix bpf_xdp_store_bytes proto for read-only arg<br /> <br /> While making some maps in Cilium read-only from the BPF side, we noticed<br /> that the bpf_xdp_store_bytes proto is incorrect. In particular, the<br /> verifier was throwing the following error:<br /> <br /> ; ret = ctx_store_bytes(ctx, l3_off + offsetof(struct iphdr, saddr),<br /> &amp;nat-&gt;address, 4, 0);<br /> 635: (79) r1 = *(u64 *)(r10 -144) ; R1=ctx() R10=fp0 fp-144=ctx()<br /> 636: (b4) w2 = 26 ; R2=26<br /> 637: (b4) w4 = 4 ; R4=4<br /> 638: (b4) w5 = 0 ; R5=0<br /> 639: (85) call bpf_xdp_store_bytes#190<br /> write into map forbidden, value_size=6 off=0 size=4<br /> <br /> nat comes from a BPF_F_RDONLY_PROG map, so R3 is a PTR_TO_MAP_VALUE.<br /> The verifier checks the helper&amp;#39;s memory access to R3 in<br /> check_mem_size_reg, as it reaches ARG_CONST_SIZE argument. The third<br /> argument has expected type ARG_PTR_TO_UNINIT_MEM, which includes the<br /> MEM_WRITE flag. The verifier thus checks for a BPF_WRITE access on R3.<br /> Given R3 points to a read-only map, the check fails.<br /> <br /> Conversely, ARG_PTR_TO_UNINIT_MEM can also lead to the helper reading<br /> from uninitialized memory.<br /> <br /> This patch simply fixes the expected argument type to match that of<br /> bpf_skb_store_bytes.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Fix memleak of newsk in unix_stream_connect().<br /> <br /> When prepare_peercred() fails in unix_stream_connect(),<br /> unix_release_sock() is not called for newsk, and the memory<br /> is leaked.<br /> <br /> Let&amp;#39;s move prepare_peercred() before unix_create1().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid1: fix memory leak in raid1_run()<br /> <br /> raid1_run() calls setup_conf() which registers a thread via<br /> md_register_thread(). If raid1_set_limits() fails, the previously<br /> registered thread is not unregistered, resulting in a memory leak<br /> of the md_thread structure and the thread resource itself.<br /> <br /> Add md_unregister_thread() to the error path to properly cleanup<br /> the thread, which aligns with the error handling logic of other paths<br /> in this function.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: do not account for OoO in mptcp_rcvbuf_grow()<br /> <br /> MPTCP-level OoOs are physiological when multiple subflows are active<br /> concurrently and will not cause retransmissions nor are caused by<br /> drops.<br /> <br /> Accounting for them in mptcp_rcvbuf_grow() causes the rcvbuf slowly<br /> drifting towards tcp_rmem[2].<br /> <br /> Remove such accounting. Note that subflows will still account for TCP-level<br /> OoO when the MPTCP-level rcvbuf is propagated.<br /> <br /> This also closes a subtle and very unlikely race condition with rcvspace<br /> init; active sockets with user-space holding the msk-level socket lock,<br /> could complete such initialization in the receive callback, after that the<br /> first OoO data reaches the rcvbuf and potentially triggering a divide by<br /> zero Oops.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: arizona: Fix regulator resource leak on wm5102_clear_write_sequencer() failure<br /> <br /> The wm5102_clear_write_sequencer() helper may return an error<br /> and just return, bypassing the cleanup sequence and causing<br /> regulators to remain enabled, leading to a resource leak.<br /> <br /> Change the direct return to jump to the err_reset label to<br /> properly free the resources.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/gcs: Fix error handling in arch_set_shadow_stack_status()<br /> <br /> alloc_gcs() returns an error-encoded pointer on failure, which comes<br /> from do_mmap(), not NULL.<br /> <br /> The current NULL check fails to detect errors, which could lead to using<br /> an invalid GCS address.<br /> <br /> Use IS_ERR_VALUE() to properly detect errors, consistent with the<br /> check in gcs_alloc_thread_stack().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: intel-ish-hid: fix NULL-ptr-deref in ishtp_bus_remove_all_clients<br /> <br /> During a warm reset flow, the cl-&gt;device pointer may be NULL if the<br /> reset occurs while clients are still being enumerated. Accessing<br /> cl-&gt;device-&gt;reference_count without a NULL check leads to a kernel panic.<br /> <br /> This issue was identified during multi-unit warm reboot stress clycles.<br /> Add a defensive NULL check for cl-&gt;device to ensure stability under<br /> such intensive testing conditions.<br /> <br /> KASAN: null-ptr-deref in range [0000000000000000-0000000000000007]<br /> Workqueue: ish_fw_update_wq fw_reset_work_fn<br /> <br /> Call Trace:<br /> ishtp_bus_remove_all_clients+0xbe/0x130 [intel_ishtp]<br /> ishtp_reset_handler+0x85/0x1a0 [intel_ishtp]<br /> fw_reset_work_fn+0x8a/0xc0 [intel_ish_ipc]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix watch_id bounds checking in debug address watch v2<br /> <br /> The address watch clear code receives watch_id as an unsigned value<br /> (u32), but some helper functions were using a signed int and checked<br /> bits by shifting with watch_id.<br /> <br /> If a very large watch_id is passed from userspace, it can be converted<br /> to a negative value. This can cause invalid shifts and may access<br /> memory outside the watch_points array.<br /> <br /> drm/amdkfd: Fix watch_id bounds checking in debug address watch v2<br /> <br /> Fix this by checking that watch_id is within MAX_WATCH_ADDRESSES before<br /> using it. Also use BIT(watch_id) to test and clear bits safely.<br /> <br /> This keeps the behavior unchanged for valid watch IDs and avoids<br /> undefined behavior for invalid ones.<br /> <br /> Fixes the below:<br /> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_debug.c:448<br /> kfd_dbg_trap_clear_dev_address_watch() error: buffer overflow<br /> &amp;#39;pdd-&gt;watch_points&amp;#39; 4 dev-&gt;kfd-&gt;shared_resources.enable_mes) {<br /> 442 r = debug_lock_and_unmap(pdd-&gt;dev-&gt;dqm);<br /> 443 if (r)<br /> 444 return r;<br /> 445 }<br /> 446<br /> 447 amdgpu_gfx_off_ctrl(pdd-&gt;dev-&gt;adev, false);<br /> --&gt; 448 pdd-&gt;watch_points[watch_id] = pdd-&gt;dev-&gt;kfd2kgd-&gt;clear_address_watch(<br /> 449 pdd-&gt;dev-&gt;adev,<br /> 450 watch_id);<br /> <br /> v2: (as per, Jonathan Kim)<br /> - Add early watch_id &gt;= MAX_WATCH_ADDRESSES validation in the set path to<br /> match the clear path.<br /> - Drop the redundant bounds check in kfd_dbg_owns_dev_watch_id().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: bq25980: Fix use-after-free in power_supply_changed()<br /> <br /> Using the `devm_` variant for requesting IRQ _before_ the `devm_`<br /> variant for allocating/registering the `power_supply` handle, means that<br /> the `power_supply` handle will be deallocated/unregistered _before_ the<br /> interrupt handler (since `devm_` naturally deallocates in reverse<br /> allocation order). This means that during removal, there is a race<br /> condition where an interrupt can fire just _after_ the `power_supply`<br /> handle has been freed, *but* just _before_ the corresponding<br /> unregistration of the IRQ handler has run.<br /> <br /> This will lead to the IRQ handler calling `power_supply_changed()` with<br /> a freed `power_supply` handle. Which usually crashes the system or<br /> otherwise silently corrupts the memory...<br /> <br /> Note that there is a similar situation which can also happen during<br /> `probe()`; the possibility of an interrupt firing _before_ registering<br /> the `power_supply` handle. This would then lead to the nasty situation<br /> of using the `power_supply` handle *uninitialized* in<br /> `power_supply_changed()`.<br /> <br /> Fix this racy use-after-free by making sure the IRQ is requested _after_<br /> the registration of the `power_supply` handle.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/P2PDMA: Release per-CPU pgmap ref when vm_insert_page() fails<br /> <br /> When vm_insert_page() fails in p2pmem_alloc_mmap(), p2pmem_alloc_mmap()<br /> doesn&amp;#39;t invoke percpu_ref_put() to free the per-CPU ref of pgmap acquired<br /> after gen_pool_alloc_owner(), and memunmap_pages() will hang forever when<br /> trying to remove the PCI device.<br /> <br /> Fix it by adding the missed percpu_ref_put().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: mediatek: svs: Fix memory leak in svs_enable_debug_write()<br /> <br /> In svs_enable_debug_write(), the buf allocated by memdup_user_nul()<br /> is leaked if kstrtoint() fails.<br /> <br /> Fix this by using __free(kfree) to automatically free buf, eliminating<br /> the need for explicit kfree() calls and preventing leaks.<br /> <br /> [Angelo: Added missing cleanup.h inclusion]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: act8945a: Fix use-after-free in power_supply_changed()<br /> <br /> Using the `devm_` variant for requesting IRQ _before_ the `devm_`<br /> variant for allocating/registering the `power_supply` handle, means that<br /> the `power_supply` handle will be deallocated/unregistered _before_ the<br /> interrupt handler (since `devm_` naturally deallocates in reverse<br /> allocation order). This means that during removal, there is a race<br /> condition where an interrupt can fire just _after_ the `power_supply`<br /> handle has been freed, *but* just _before_ the corresponding<br /> unregistration of the IRQ handler has run.<br /> <br /> This will lead to the IRQ handler calling `power_supply_changed()` with<br /> a freed `power_supply` handle. Which usually crashes the system or<br /> otherwise silently corrupts the memory...<br /> <br /> Note that there is a similar situation which can also happen during<br /> `probe()`; the possibility of an interrupt firing _before_ registering<br /> the `power_supply` handle. This would then lead to the nasty situation<br /> of using the `power_supply` handle *uninitialized* in<br /> `power_supply_changed()`.<br /> <br /> Fix this racy use-after-free by making sure the IRQ is requested _after_<br /> the registration of the `power_supply` handle.