Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/migrate_device: fix spinlock leak in migrate_vma_insert_huge_pmd_page<br /> <br /> When check_stable_address_space() fails after the PMD spinlock has<br /> been acquired via pmd_lock(), the code jumps directly to the abort<br /> label, bypassing the spin_unlock() call in unlock_abort. This causes<br /> the PMD spinlock to be permanently held, leading to a deadlock.<br /> <br /> Change the goto target from abort to unlock_abort to ensure the<br /> spinlock is always released on this error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free<br /> <br /> __GFP_ZEROTAGS semantics are currently a bit weird, but effectively this<br /> flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN.<br /> <br /> If we run with init_on_free, we will zero out pages during<br /> __free_pages_prepare(), to skip zeroing on the allocation path.<br /> <br /> However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will<br /> consequently not only skip clearing page content, but also skip clearing<br /> tag memory.<br /> <br /> Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that<br /> will get mapped to user space through set_pte_at() later: set_pte_at() and<br /> friends will detect that the tags have not been initialized yet<br /> (PG_mte_tagged not set), and initialize them.<br /> <br /> However, for the huge zero folio, which will be mapped through a PMD<br /> marked as special, this initialization will not be performed, ending up<br /> exposing whatever tags were still set for the pages.<br /> <br /> The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state<br /> that allocation tags are set to 0 when a page is first mapped to user<br /> space. That no longer holds with the huge zero folio when init_on_free is<br /> enabled.<br /> <br /> Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to<br /> tag_clear_highpages() whether we want to also clear page content.<br /> <br /> Invert the meaning of the tag_clear_highpages() return value to have<br /> clearer semantics.<br /> <br /> Reproduced with the huge zero folio by modifying the check_buffer_fill<br /> arm64/mte selftest to use a 2 MiB area, after making sure that pages have<br /> a non-0 tag set when freeing (note that, during boot, we will not actually<br /> initialize tags, but only set KASAN_TAG_KERNEL in the page flags).<br /> <br /> $ ./check_buffer_fill<br /> 1..20<br /> ...<br /> not ok 17 Check initial tags with private mapping, sync error mode and mmap memory<br /> not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory<br /> ...<br /> <br /> This code needs more cleanups; we&amp;#39;ll tackle that next, like<br /> decoupling __GFP_ZEROTAGS from __GFP_SKIP_KASAN.<br /> <br /> [akpm@linux-foundation.org: s/__GPF_ZERO/__GFP_ZERO/, per David]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/memory: fix spurious warning when unmapping device-private/exclusive pages<br /> <br /> Device private and exclusive entries are only supported for anonymous<br /> folios. This condition is tested in __migrate_device_pages() and<br /> make_device_exclusive() using folio_test_anon(). However the unmap path<br /> tests this assumption using vma_is_anonymous().<br /> <br /> This is wrong because whilst anonymous VMAs can only contain folios where<br /> folio_test_anon() is true the opposite relation does not hold. A folio<br /> for which folio_test_anon() is true does not imply vma_is_anonymous() is<br /> true. Such a condition can occur if for example a folio is part of a<br /> private filebacked mapping.<br /> <br /> In this case vma_is_anonymous() is false as the mapping is filebacked, but<br /> folio_test_anon() may be true, thus permitting devices to migrate the<br /> folio to device private memory. This can lead to the following spurious<br /> warnings during process teardown:<br /> <br /> [ 772.737706] ------------[ cut here ]------------<br /> [ 772.739201] WARNING: mm/memory.c:1754 at unmap_page_range.cold+0x26/0x18a, CPU#17: hmm-tests/2041<br /> [ 772.742050] Modules linked in: test_hmm nvidia_uvm(O) nvidia(O)<br /> [ 772.743959] CPU: 17 UID: 0 PID: 2041 Comm: hmm-tests Tainted: G W O 7.0.0+ #387 PREEMPT(full)<br /> [ 772.747104] Tainted: [W]=WARN, [O]=OOT_MODULE<br /> [ 772.748509] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014<br /> [ 772.752117] RIP: 0010:unmap_page_range.cold+0x26/0x18a<br /> [ 772.753780] Code: 7e fe ff ff 48 89 4c 24 78 4c 89 44 24 38 e8 f2 ff b1 00 48 8b 4c 24 78 4c 8b 44 24 38 48 8b 44 24 18 48 83 78 48 00 74 04 90 0b 90 48 89 ca b8 ff ff 37 00 48 c1 ea 03 48 c1 e0 2a 80 3c 02<br /> [ 772.759602] RSP: 0018:ffff888112607550 EFLAGS: 00010286<br /> [ 772.761310] RAX: ffff88811bbf4dc0 RBX: dffffc0000000000 RCX: ffffea03e9bfffd8<br /> [ 772.763583] RDX: 1ffff1102377e9c1 RSI: 0000000000000008 RDI: ffff88811bbf4e08<br /> [ 772.765914] RBP: 0000000000000006 R08: ffff8881059f7448 R09: ffffed10224c0e68<br /> [ 772.768184] R10: ffff888112607347 R11: 0000000000000001 R12: 0000000000000001<br /> [ 772.770461] R13: ffffea03e9bfffc0 R14: ffff888112607908 R15: ffffea03e9bfffc0<br /> [ 772.772782] FS: 00007f327caa2780(0000) GS:ffff888427b7d000(0000) knlGS:0000000000000000<br /> [ 772.775328] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 772.777187] CR2: 00007f327ca89000 CR3: 00000001994d5000 CR4: 00000000000006f0<br /> [ 772.779135] Call Trace:<br /> [ 772.779792] <br /> [ 772.780317] ? dmirror_interval_invalidate+0x1a3/0x290 [test_hmm]<br /> [ 772.781873] ? vm_normal_page_pud+0x2b0/0x2b0<br /> [ 772.782992] ? __rwlock_init+0x150/0x150<br /> [ 772.784006] ? lock_release+0x216/0x2b0<br /> [ 772.785008] ? __mmu_notifier_invalidate_range_start+0x505/0x6e0<br /> [ 772.786522] ? lock_release+0x216/0x2b0<br /> [ 772.787498] ? unmap_single_vma+0xb6/0x210<br /> [ 772.788573] unmap_vmas+0x27d/0x520<br /> [ 772.789506] ? unmap_single_vma+0x210/0x210<br /> [ 772.790607] ? mas_update_gap.part.0+0x620/0x620<br /> [ 772.791834] unmap_region+0x19e/0x350<br /> [ 772.792769] ? remove_vma+0x130/0x130<br /> [ 772.793684] ? mas_alloc_nodes+0x1f2/0x300<br /> [ 772.794730] vms_complete_munmap_vmas+0x8c1/0xe20<br /> [ 772.795926] ? unmap_region+0x350/0x350<br /> [ 772.796917] do_vmi_align_munmap+0x36a/0x4e0<br /> [ 772.798018] ? lock_release+0x216/0x2b0<br /> [ 772.799024] ? vma_shrink+0x620/0x620<br /> [ 772.799983] do_vmi_munmap+0x150/0x2c0<br /> [ 772.800939] __vm_munmap+0x161/0x2c0<br /> [ 772.801872] ? expand_downwards+0xd60/0xd60<br /> [ 772.802948] ? clockevents_program_event+0x1ef/0x540<br /> [ 772.804217] ? lock_release+0x216/0x2b0<br /> [ 772.805158] __x64_sys_munmap+0x59/0x80<br /> [ 772.805776] do_syscall_64+0xfc/0x670<br /> [ 772.806336] ? irqentry_exit+0xda/0x580<br /> [ 772.806976] entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> [ 772.807772] RIP: 0033:0x7f327cbb2717<br /> [ 772.808323] Code: 73 01 c3 48 8b 0d f9 76 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 0b 00 00 00 0f 05 3d 01 f0 ff<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: devmem: reject dma-buf bind with non-page-aligned size or SG length<br /> <br /> net_devmem_bind_dmabuf() trusts dmabuf-&gt;size and sg_dma_len() to be<br /> PAGE_SIZE multiples without checking:<br /> <br /> - tx_vec is sized dmabuf-&gt;size / PAGE_SIZE, and<br /> net_devmem_get_niov_at() only bounds-checks virt_addr size<br /> before indexing tx_vec[virt_addr / PAGE_SIZE]. With size =<br /> N*PAGE_SIZE + r (1 size); the<br /> SG-length check covers both directions.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bcmgenet: keep RBUF EEE/PM disabled<br /> <br /> Setting RBUF_EEE_EN | RBUF_PM_EN in RBUF_ENERGY_CTRL breaks the RX<br /> path on GENET hardware once MAC EEE becomes active. RX traffic stops<br /> flowing while the link stays up and the usual descriptor/RX error<br /> counters remain quiet. In that state the MAC still accepts frames<br /> (rbuf_ovflow_cnt keeps climbing) but RBUF no longer forwards them to<br /> DMA, so rx_packets is no longer incremented at the netdev level. On<br /> some boards the corruption ends up as a paging fault in<br /> skb_release_data via bcmgenet_rx_poll on an LPI exit.<br /> <br /> Reproduced on Pi 4B (BCM2711 + BCM54213PE) and confirmed by Florian<br /> Fainelli on an internal Broadcom 4908-family board with the same crash<br /> signature. RBUF_PM_EN is not publicly documented.<br /> <br /> This shows up more often now that phy_support_eee() enables EEE by<br /> default, but it also affects older kernels as soon as TX LPI is<br /> turned on via ethtool, so it is not specific to recent changes.<br /> <br /> Always clear RBUF_EEE_EN | RBUF_PM_EN in bcmgenet_eee_enable_set so<br /> the bits stay off across resets. UMAC and TBUF setup is left alone so<br /> TX-side EEE keeps working.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: validate Add Extended Advertising Data length<br /> <br /> MGMT_OP_ADD_EXT_ADV_DATA is registered as a variable-length command,<br /> with MGMT_ADD_EXT_ADV_DATA_SIZE as the fixed header size. The handler<br /> then uses cp-&gt;adv_data_len and cp-&gt;scan_rsp_len to validate and copy<br /> cp-&gt;data, but it never checks that those bytes are part of the mgmt<br /> command payload.<br /> <br /> A short command can therefore make add_ext_adv_data() pass an<br /> out-of-bounds pointer into tlv_data_is_valid(). If the bytes beyond<br /> the command buffer are addressable, they can also be copied into the<br /> advertising instance as scan response data, where the caller can read<br /> them back via MGMT_OP_GET_ADV_INSTANCE. The trigger requires<br /> CAP_NET_ADMIN in the initial user namespace; KASAN reports an 8-byte<br /> slab-out-of-bounds read.<br /> <br /> Reject commands whose length does not match the fixed header plus both<br /> advertising data lengths before parsing cp-&gt;data.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: use list_del_rcu in l2tp_session_unhash<br /> <br /> An unprivileged local user can pin a host CPU indefinitely in<br /> l2tp_session_get_by_ifname() by issuing L2TP_CMD_SESSION_GET on<br /> L2TP_ATTR_IFNAME concurrently with L2TP_CMD_SESSION_CREATE and<br /> L2TP_CMD_SESSION_DELETE on the same tunnel. All three commands take<br /> GENL_UNS_ADMIN_PERM, so CAP_NET_ADMIN in the netns user namespace<br /> suffices; on any host that has l2tp_core loaded the trigger is<br /> reachable from a standard `unshare -Urn` sandbox.<br /> <br /> l2tp_session_unhash() removes a session from tunnel-&gt;session_list<br /> with list_del_init(), but that list is walked by<br /> l2tp_session_get_by_ifname() with list_for_each_entry_rcu() under<br /> rcu_read_lock_bh(). list_del_init() leaves the deleted entry&amp;#39;s<br /> next/prev self-pointing; a reader that has loaded the entry and<br /> then advances pos-&gt;list.next reads &amp;session-&gt;list, container_of()s<br /> back to the same session, and list_for_each_entry_rcu() never<br /> reaches the list head. The CPU stays in strcmp() inside the<br /> walker, with BH and preemption disabled, so RCU grace periods on<br /> the host stall behind it and the wedged thread cannot be killed<br /> (SIGKILL is delivered on syscall return).<br /> <br /> Use list_del_rcu() to match the existing list_add_rcu() in<br /> l2tp_session_register(); the deleted session remains visible to<br /> in-flight walkers with consistent next/prev pointers until<br /> kfree_rcu() in l2tp_session_free() releases it. tunnel-&gt;session_list<br /> has exactly one list_del_init() call site; the list_del_init<br /> (&amp;session-&gt;clist) at l2tp_core.c:533 operates on the per-collision<br /> list, which is not walked under RCU. list_empty(&amp;session-&gt;list) is<br /> not used anywhere in net/l2tp/ after the unhash point, so dropping<br /> the post-delete self-init is safe; the fix has no userspace-visible<br /> behavior change.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethtool: fix NULL pointer dereference in phy_reply_size<br /> <br /> In phy_prepare_data(), several strings such as &amp;#39;name&amp;#39;, &amp;#39;drvname&amp;#39;,<br /> &amp;#39;upstream_sfp_name&amp;#39;, and &amp;#39;downstream_sfp_name&amp;#39; are allocated using<br /> kstrdup(). However, these allocations were not checked for failure.<br /> <br /> If kstrdup() fails for &amp;#39;name&amp;#39;, it returns NULL while the function<br /> continues. This leads to a kernel NULL pointer dereference and panic<br /> later in phy_reply_size() when it unconditionally calls strlen() on<br /> the NULL pointer.<br /> <br /> While other strings like &amp;#39;upstream_sfp_name&amp;#39; might be checked before<br /> access in certain code paths, failing to handle these allocations<br /> consistently can lead to incomplete data reporting or hidden bugs.<br /> <br /> Fix this by adding proper NULL checks for all kstrdup() calls in<br /> phy_prepare_data() and implement a centralized error handling path<br /> using goto labels to ensure all previously allocated resources are<br /> freed on failure.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ifb: report ethtool stats over num_tx_queues<br /> <br /> ifb_dev_init() allocates dp-&gt;tx_private to dev-&gt;num_tx_queues<br /> entries via kzalloc_objs(*txp, dev-&gt;num_tx_queues). Both IFB<br /> per-queue RX and TX stats live in those entries: ifb_xmit() updates<br /> txp-&gt;rx_stats using the skb queue mapping, ifb_ri_tasklet() updates<br /> txp-&gt;tx_stats, and ifb_stats64() aggregates both over<br /> dev-&gt;num_tx_queues.<br /> <br /> The ethtool stats callbacks instead size and walk the per-queue<br /> stats with dev-&gt;real_num_rx_queues and dev-&gt;real_num_tx_queues. With<br /> an asymmetric device where the RX queue count exceeds the TX queue<br /> count, for example:<br /> <br /> ip link add name ifb10 numtxqueues 1 numrxqueues 8 type ifb<br /> ethtool -S ifb10<br /> <br /> ifb_get_ethtool_stats() indexes past the tx_private allocation and<br /> copies adjacent slab data through ETHTOOL_GSTATS.<br /> <br /> Use dev-&gt;num_tx_queues consistently for the stats strings, the<br /> stats count, and the stats data walks. This reports one RX stats<br /> group and one TX stats group for each backing ifb_q_private entry,<br /> which is the queue set IFB can actually populate.<br /> <br /> Reproduced under UML+KASAN at v7.1-rc2:<br /> <br /> BUG: KASAN: slab-out-of-bounds in ifb_fill_stats_data+0x3c/0xae<br /> Read of size 8 at addr 0000000062dbd228 by task ethtool/36<br /> ifb_fill_stats_data+0x3c/0xae<br /> ifb_get_ethtool_stats+0xc0/0x129<br /> __dev_ethtool+0x1ca5/0x363c<br /> dev_ethtool+0x123/0x1b3<br /> dev_ioctl+0x56c/0x744<br /> sock_do_ioctl+0x15f/0x1b2<br /> sock_ioctl+0x4d5/0x50a<br /> sys_ioctl+0xd8b/0xde9<br /> <br /> With the patch applied, the same UML+KASAN repro is silent and<br /> ethtool -S ifb10 reports only the stats backed by the single<br /> allocated tx_private entry.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: ioam: add NULL check for idev in ipv6_hop_ioam()<br /> <br /> Reported by Sashiko:<br /> <br /> The function ipv6_hop_ioam() accesses<br /> __in6_dev_get(skb-&gt;dev)-&gt;cnf.ioam6_enabled without validating the returned<br /> idev pointer. Because addrconf_ifdown() can concurrently clear dev-&gt;ip6_ptr<br /> via RCU, __in6_dev_get() can return NULL during interface teardown, which<br /> could cause a NULL pointer dereference when processing an IOAM Hop-by-Hop<br /> option.<br /> <br /> Let&amp;#39;s add a check and use SKB_DROP_REASON_IPV6DISABLED accordingly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: capture fast-RX rate before mesh reuses skb-&gt;cb<br /> <br /> ieee80211_invoke_fast_rx() reads RX status through<br /> IEEE80211_SKB_RXCB(skb), which aliases the same skb-&gt;cb storage<br /> that ieee80211_rx_mesh_data() reuses as IEEE80211_TX_INFO. In the<br /> unicast forward path, mesh_data does:<br /> <br /> info = IEEE80211_SKB_CB(fwd_skb);<br /> memset(info, 0, sizeof(*info));<br /> <br /> on the same skb the caller still names via rx-&gt;skb, then either<br /> queues the skb for TX (success) or kfree_skb()&amp;#39;s it (no-route)<br /> before returning RX_QUEUED. The caller&amp;#39;s RX_QUEUED arm then<br /> calls sta_stats_encode_rate(status) on memory that is either<br /> zeroed (success path) or freed (no-route path). The latter is<br /> KASAN slab-use-after-free in ieee80211_prepare_and_rx_handle.<br /> <br /> Fix by encoding the rate from status before invoking<br /> ieee80211_rx_mesh_data(), so the RX_QUEUED arm consumes a value<br /> captured while status was still backed by valid memory.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> qed: fix double free in qed_cxt_tables_alloc()<br /> <br /> If one of the later PF or VF CID bitmap allocations fails,<br /> qed_cid_map_alloc() jumps to cid_map_fail and frees the previously<br /> allocated CID bitmaps before returning an error. qed_cxt_tables_alloc()<br /> then calls qed_cxt_mngr_free(), which invokes qed_cid_map_free()<br /> again.<br /> <br /> Fix this by setting each CID bitmap pointer to NULL after bitmap_free()<br /> to avoid double free.<br /> <br /> The bug was first flagged by an experimental analysis tool we are<br /> developing for kernel memory-management bugs while analyzing<br /> v6.13-rc1. The tool is still under development and is not yet publicly<br /> available. Manual inspection confirms that the bug is still<br /> present in v7.1-rc3.<br /> <br /> Runtime reproduction was not attempted because exercising the failing<br /> allocation path requires device-specific setup.