Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: ti: pruss: Fix double free in pruss_clk_mux_setup()<br /> <br /> In the pruss_clk_mux_setup(), the devm_add_action_or_reset() indirectly<br /> calls pruss_of_free_clk_provider(), which calls of_node_put(clk_mux_np)<br /> on the error path. However, after the devm_add_action_or_reset()<br /> returns, the of_node_put(clk_mux_np) is called again, causing a double<br /> free.<br /> <br /> Fix by returning directly, to avoid the duplicate of_node_put().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netconsole: avoid OOB reads, msg is not nul-terminated<br /> <br /> msg passed to netconsole from the console subsystem is not guaranteed<br /> to be nul-terminated. Before recent<br /> commit 7eab73b18630 ("netconsole: convert to NBCON console infrastructure")<br /> the message would be placed in printk_shared_pbufs, a static global<br /> buffer, so KASAN had harder time catching OOB accesses. Now we see:<br /> <br /> printk: console [netcon_ext0] enabled<br /> BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240<br /> Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594<br /> <br /> CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9<br /> Call Trace:<br /> kasan_report+0xe4/0x120<br /> string+0x1f7/0x240<br /> vsnprintf+0x655/0xba0<br /> scnprintf+0xba/0x120<br /> netconsole_write+0x3fe/0xa10<br /> nbcon_emit_next_record+0x46e/0x860<br /> nbcon_kthread_func+0x623/0x750<br /> <br /> Allocated by task 1:<br /> nbcon_alloc+0x1ea/0x450<br /> register_console+0x26b/0xe10<br /> init_netconsole+0xbb0/0xda0<br /> <br /> The buggy address belongs to the object at ffff88813b6d4000<br /> which belongs to the cache kmalloc-4k of size 4096<br /> The buggy address is located 0 bytes to the right of<br /> allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: fix potential race in tcp_v6_syn_recv_sock()<br /> <br /> Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock()<br /> is done too late.<br /> <br /> After tcp_v4_syn_recv_sock(), the child socket is already visible<br /> from TCP ehash table and other cpus might use it.<br /> <br /> Since newinet-&gt;pinet6 is still pointing to the listener ipv6_pinfo<br /> bad things can happen as syzbot found.<br /> <br /> Move the problematic code in tcp_v6_mapped_child_init()<br /> and call this new helper from tcp_v4_syn_recv_sock() before<br /> the ehash insertion.<br /> <br /> This allows the removal of one tcp_sync_mss(), since<br /> tcp_v4_syn_recv_sock() will call it with the correct<br /> context.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query<br /> <br /> Fix a "scheduling while atomic" bug in mlx5e_ipsec_init_macs() by<br /> replacing mlx5_query_mac_address() with ether_addr_copy() to get the<br /> local MAC address directly from netdev-&gt;dev_addr.<br /> <br /> The issue occurs because mlx5_query_mac_address() queries the hardware<br /> which involves mlx5_cmd_exec() that can sleep, but it is called from<br /> the mlx5e_ipsec_handle_event workqueue which runs in atomic context.<br /> <br /> The MAC address is already available in netdev-&gt;dev_addr, so no need<br /> to query hardware. This avoids the sleeping call and resolves the bug.<br /> <br /> Call trace:<br /> BUG: scheduling while atomic: kworker/u112:2/69344/0x00000200<br /> __schedule+0x7ab/0xa20<br /> schedule+0x1c/0xb0<br /> schedule_timeout+0x6e/0xf0<br /> __wait_for_common+0x91/0x1b0<br /> cmd_exec+0xa85/0xff0 [mlx5_core]<br /> mlx5_cmd_exec+0x1f/0x50 [mlx5_core]<br /> mlx5_query_nic_vport_mac_address+0x7b/0xd0 [mlx5_core]<br /> mlx5_query_mac_address+0x19/0x30 [mlx5_core]<br /> mlx5e_ipsec_init_macs+0xc1/0x720 [mlx5_core]<br /> mlx5e_ipsec_build_accel_xfrm_attrs+0x422/0x670 [mlx5_core]<br /> mlx5e_ipsec_handle_event+0x2b9/0x460 [mlx5_core]<br /> process_one_work+0x178/0x2e0<br /> worker_thread+0x2ea/0x430

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: validate user queue size constraints<br /> <br /> Add validation to ensure user queue sizes meet hardware requirements:<br /> - Size must be a power of two for efficient ring buffer wrapping<br /> - Size must be at least AMDGPU_GPU_PAGE_SIZE to prevent undersized allocations<br /> <br /> This prevents invalid configurations that could lead to GPU faults or<br /> unexpected behavior.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix nfs4_file refcount leak in nfsd_get_dir_deleg()<br /> <br /> Claude pointed out that there is a nfs4_file refcount leak in<br /> nfsd_get_dir_deleg(). Ensure that the reference to "fp" is released<br /> before returning.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm mpath: Add missing dm_put_device when failing to get scsi dh name<br /> <br /> When commit fd81bc5cca8f ("scsi: device_handler: Return error pointer in<br /> scsi_dh_attached_handler_name()") added code to fail parsing the path if<br /> scsi_dh_attached_handler_name() failed with -ENOMEM, it didn&amp;#39;t clean up<br /> the reference to the path device that had just been taken. Fix this, and<br /> steamline the error paths of parse_path() a little.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: do not propagate page array emplacement errors as batch errors<br /> <br /> When fscrypt is enabled, move_dirty_folio_in_page_array() may fail<br /> because it needs to allocate bounce buffers to store the encrypted<br /> versions of each folio. Each folio beyond the first allocates its bounce<br /> buffer with GFP_NOWAIT. Failures are common (and expected) under this<br /> allocation mode; they should flush (not abort) the batch.<br /> <br /> However, ceph_process_folio_batch() uses the same `rc` variable for its<br /> own return code and for capturing the return codes of its routine calls;<br /> failing to reset `rc` back to 0 results in the error being propagated<br /> out to the main writeback loop, which cannot actually tolerate any<br /> errors here: once `ceph_wbc.pages` is allocated, it must be passed to<br /> ceph_submit_write() to be freed. If it survives until the next iteration<br /> (e.g. due to the goto being followed), ceph_allocate_page_array()&amp;#39;s<br /> BUG_ON() will oops the worker.<br /> <br /> Note that this failure mode is currently masked due to another bug<br /> (addressed next in this series) that prevents multiple encrypted folios<br /> from being selected for the same write.<br /> <br /> For now, just reset `rc` when redirtying the folio to prevent errors in<br /> move_dirty_folio_in_page_array() from propagating. Note that<br /> move_dirty_folio_in_page_array() is careful never to return errors on<br /> the first folio, so there is no need to check for that. After this<br /> change, ceph_process_folio_batch() no longer returns errors; its only<br /> remaining failure indicator is `locked_pages == 0`, which the caller<br /> already handles correctly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: delete attr leaf freemap entries when empty<br /> <br /> Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size<br /> underflow"), Brian Foster observed that it&amp;#39;s possible for a small<br /> freemap at the end of the end of the xattr entries array to experience<br /> a size underflow when subtracting the space consumed by an expansion of<br /> the entries array. There are only three freemap entries, which means<br /> that it is not a complete index of all free space in the leaf block.<br /> <br /> This code can leave behind a zero-length freemap entry with a nonzero<br /> base. Subsequent setxattr operations can increase the base up to the<br /> point that it overlaps with another freemap entry. This isn&amp;#39;t in and of<br /> itself a problem because the code in _leaf_add that finds free space<br /> ignores any freemap entry with zero size.<br /> <br /> However, there&amp;#39;s another bug in the freemap update code in _leaf_add,<br /> which is that it fails to update a freemap entry that begins midway<br /> through the xattr entry that was just appended to the array. That can<br /> result in the freemap containing two entries with the same base but<br /> different sizes (0 for the "pushed-up" entry, nonzero for the entry<br /> that&amp;#39;s actually tracking free space). A subsequent _leaf_add can then<br /> allocate xattr namevalue entries on top of the entries array, leading to<br /> data loss. But fixing that is for later.<br /> <br /> For now, eliminate the possibility of confusion by zeroing out the base<br /> of any freemap entry that has zero size. Because the freemap is not<br /> intended to be a complete index of free space, a subsequent failure to<br /> find any free space for a new xattr will trigger block compaction, which<br /> regenerates the freemap.<br /> <br /> It looks like this bug has been in the codebase for quite a long time.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()<br /> <br /> On the receive path, __ioam6_fill_trace_data() uses trace-&gt;nodelen<br /> to decide how much data to write for each node. It trusts this field<br /> as-is from the incoming packet, with no consistency check against<br /> trace-&gt;type (the 24-bit field that tells which data items are<br /> present). A crafted packet can set nodelen=0 while setting type bits<br /> 0-21, causing the function to write ~100 bytes past the allocated<br /> region (into skb_shared_info), which corrupts adjacent heap memory<br /> and leads to a kernel panic.<br /> <br /> Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to<br /> derive the expected nodelen from the type field, and use it:<br /> <br /> - in ioam6_iptunnel.c (send path, existing validation) to replace<br /> the open-coded computation;<br /> - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose<br /> nodelen is inconsistent with the type field, before any data is<br /> written.<br /> <br /> Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they<br /> are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to<br /> 0xff1ffc00).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l2-async: Fix error handling on steps after finding a match<br /> <br /> Once an async connection is found to be matching with an fwnode, a<br /> sub-device may be registered (in case it wasn&amp;#39;t already), its bound<br /> operation is called, ancillary links are created, the async connection<br /> is added to the sub-device&amp;#39;s list of connections and removed from the<br /> global waiting connection list. Further on, the sub-device&amp;#39;s possible own<br /> notifier is searched for possible additional matches.<br /> <br /> Fix these specific issues:<br /> <br /> - If v4l2_async_match_notify() failed before the sub-notifier handling,<br /> the async connection was unbound and its entry removed from the<br /> sub-device&amp;#39;s async connection list. The latter part was also done in<br /> v4l2_async_match_notify().<br /> <br /> - The async connection&amp;#39;s sd field was only set after creating ancillary<br /> links in v4l2_async_match_notify(). It was however dereferenced in<br /> v4l2_async_unbind_subdev_one(), which was called on error path of<br /> v4l2_async_match_notify() failure.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: xt_tcpmss: check remaining length before reading optlen<br /> <br /> Quoting reporter:<br /> In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads<br /> op[i+1] directly without validating the remaining option length.<br /> <br /> If the last byte of the option field is not EOL/NOP (0/1), the code attempts<br /> to index op[i+1]. In the case where i + 1 == optlen, this causes an<br /> out-of-bounds read, accessing memory past the optlen boundary<br /> (either reading beyond the stack buffer _opt or the<br /> following payload).