Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binfmt_misc: don&amp;#39;t warn when the mount is completed from another user namespace<br /> <br /> fsopen() records the caller&amp;#39;s user namespace in fc-&gt;user_ns and hands<br /> back an ordinary file descriptor. Nothing ties the task that calls<br /> fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The<br /> fd is inherited across fork() and exec() and it can be passed over a<br /> unix socket.<br /> <br /> Completing a context from another user namespace is allowed on purpose.<br /> vfs_cmd_create() authorizes the create with mount_capable(), which for<br /> FS_USERNS_MOUNT checks ns_capable(fc-&gt;user_ns, CAP_SYS_ADMIN), and that<br /> succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc-&gt;user_ns.<br /> So an unprivileged task can reach the WARN_ON() in bm_fill_super():<br /> create a user and a mount namespace in a child, call<br /> fsopen("binfmt_misc") there, send the fscontext fd to the parent and let<br /> the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain<br /> unshare(1) and no capability is needed anywhere:<br /> <br /> WARNING: fs/binfmt_misc.c:938 at bm_fill_super+0xa2/0xc0 [binfmt_misc]<br /> CPU: 15 UID: 1000 PID: 3243382 Comm: fswarn<br /> Call Trace:<br /> get_tree_keyed+0x7d/0xb0<br /> bm_get_tree+0x34/0x90 [binfmt_misc]<br /> vfs_get_tree+0x2a/0x100<br /> vfs_cmd_create+0x60/0xf0<br /> __do_sys_fsconfig+0x4b2/0x500<br /> <br /> The child needs the mount namespace because fsopen() itself gates on<br /> may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning<br /> the caller&amp;#39;s mount namespace. fsconfig() doesn&amp;#39;t repeat that check.<br /> <br /> It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be<br /> raised in a loop to taint the kernel and flood the log, and it panics a<br /> kernel booted with panic_on_warn.<br /> <br /> Keep refusing the mount and stop warning about it. Nothing in<br /> bm_fill_super() depends on the two namespaces matching, it derives<br /> everything from sb-&gt;s_user_ns.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: don&amp;#39;t warn when the mount is completed from another user namespace<br /> <br /> fsopen() records the caller&amp;#39;s user namespace in fc-&gt;user_ns and hands<br /> back an ordinary file descriptor. Nothing ties the task that calls<br /> fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The<br /> fd is inherited across fork() and exec() and it can be passed over a<br /> unix socket.<br /> <br /> Completing a context from another user namespace is allowed on purpose.<br /> vfs_cmd_create() authorizes the create with mount_capable(), which for<br /> FS_USERNS_MOUNT checks ns_capable(fc-&gt;user_ns, CAP_SYS_ADMIN), and that<br /> succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc-&gt;user_ns.<br /> So an unprivileged task can reach the WARN_ON() in ovl_fill_super():<br /> create a user and a mount namespace in a child, call fsopen("overlay")<br /> there, send the fscontext fd to the parent and let the parent issue<br /> FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no<br /> capability is needed anywhere:<br /> <br /> WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay]<br /> CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn<br /> Call Trace:<br /> get_tree_nodev+0x71/0xa0<br /> ovl_get_tree+0x15/0x20 [overlay]<br /> vfs_get_tree+0x2a/0x100<br /> vfs_cmd_create+0x60/0xf0<br /> __do_sys_fsconfig+0x4b2/0x500<br /> <br /> The child needs the mount namespace because fsopen() itself gates on<br /> may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning<br /> the caller&amp;#39;s mount namespace. fsconfig() doesn&amp;#39;t repeat that check.<br /> <br /> It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be<br /> raised in a loop to taint the kernel and flood the log, and it panics a<br /> kernel booted with panic_on_warn.<br /> <br /> Keep refusing the mount and stop warning about it. ovl_parse_param()<br /> already spells a user namespace check this way for Opt_override_creds.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_gact, act_police: range check the fallback control action<br /> <br /> tcf_action_check_ctrlact() range checks the primary control action:<br /> <br /> if (!opcode)<br /> ret = action &gt; TC_ACT_VALUE_MAX ? -EINVAL : 0;<br /> <br /> TC_ACT_VALUE_MAX is TC_ACT_TRAP, so kernel-internal verdicts above it<br /> cannot be set that way. But act_gact and act_police each carry a second,<br /> independent control action supplied by user space that never reaches that<br /> helper - TCA_GACT_PROB.paction and TCA_POLICE_RESULT. Both only reject<br /> TC_ACT_GOTO_CHAIN, so any other value is stored verbatim and returned<br /> verbatim from the action.<br /> <br /> In particular user space can store TC_ACT_CONSUMED, which is<br /> TC_ACT_VALUE_MAX + 1 and is deliberately not part of the UAPI value<br /> range. That verdict tells every caller the action took ownership of the<br /> skb, so nobody frees it: sch_handle_ingress(), sch_handle_egress() and<br /> tcf_qevent_handle() all deliberately skip the free for it. The result is<br /> one leaked sk_buff plus its data buffer per packet traversing the filter,<br /> unbounded, for all traffic on the chain including kernel-generated<br /> packets.<br /> <br /> Both are trivially deterministic. act_gact clamps tcfg_pval to &gt;= 1, so<br /> with pval = 1 gact_determ() returns the fallback for every packet.<br /> act_police has no mandatory rate, so rate = 0 leaves tcfp_mtu = ~0 and<br /> tcf_police_mtu_check() always passes.<br /> <br /> TC_ACT_CONSUMED was added by commit 720f22fed81b ("net: sched: refactor<br /> reinsert action"), after both goto-chain guards were written:<br /> commit 9469f375ab09 ("net/sched: act_gact: disallow &amp;#39;goto chain&amp;#39; on<br /> fallback control action") and<br /> commit c08f5ed5d625 ("net/sched: act_police: disallow &amp;#39;goto chain&amp;#39; on<br /> fallback control action"). Neither guard was widened when the new<br /> verdict appeared.<br /> <br /> Factor the existing range test out of tcf_action_check_ctrlact() as<br /> tcf_action_valid() and apply it to both fallbacks. The helper cannot call<br /> tcf_action_check_ctrlact() directly because that also allocates a<br /> goto_chain, which is exactly what these two sites must not do.<br /> <br /> Reproduced on v7.2-rc6: kmemleak reports one leaked 232-byte<br /> skbuff_head_cache object plus its 704-byte data buffer per packet. With<br /> this patch both configurations are rejected with -EINVAL and kmemleak<br /> reports none.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_ct: fix sk_buff leak when the header checks reject a packet<br /> <br /> tcf_ct_handle_fragments() runs its header sanity checks before handing<br /> anything to the defragmentation engine:<br /> <br /> if (family == NFPROTO_IPV4)<br /> err = tcf_ct_ipv4_is_fragment(skb, &amp;frag);<br /> else<br /> err = tcf_ct_ipv6_is_fragment(skb, &amp;frag);<br /> if (err || !frag)<br /> return err;<br /> <br /> tcf_ct_ipv4_is_fragment() returns -EINVAL or -ENOMEM;<br /> tcf_ct_ipv6_is_fragment() adds -EPROTO when ipv6_find_hdr() fails. None of<br /> them frees or queues the skb, so on that path the caller still owns it.<br /> <br /> tcf_ct_act() however funnels every non-zero return into the<br /> ownership-transfer exit:<br /> <br /> err = tcf_ct_handle_fragments(net, skb, family, p-&gt;zone, &amp;defrag);<br /> if (err)<br /> goto out_frag;<br /> ...<br /> out_frag:<br /> if (err != -EINPROGRESS)<br /> tcf_action_inc_drop_qstats(&amp;c-&gt;common);<br /> return TC_ACT_CONSUMED;<br /> <br /> TC_ACT_CONSUMED means the action took ownership of the skb, so no caller<br /> frees it - sch_handle_ingress(), sch_handle_egress() and<br /> tcf_qevent_handle() all deliberately skip the free for that verdict. The<br /> skb is therefore orphaned: one sk_buff plus its data buffer is leaked per<br /> malformed packet, unbounded. Note the drop counter is already incremented<br /> for these errors, so the statistics claim a drop that never happens.<br /> <br /> Three different ownership states reach out_frag: today - the skb may be<br /> queued by the defrag engine (-EINPROGRESS), already freed by<br /> nf_ct_handle_fragments(), or still owned by us. Tell the caller which of<br /> those it is, and free the packet ourselves in the last case, which<br /> restores the TC_ACT_SHOT behaviour that predated the Fixes: commit.<br /> <br /> Reproduced on v7.2-rc6 with a 54-byte frame carrying a 40-byte IPv6<br /> header with nexthdr = 0 (hop-by-hop) and nothing after it, on a<br /> clsact ingress chain with "action ct". kmemleak reports one leaked<br /> 232-byte skbuff_head_cache object plus its 704-byte data buffer per<br /> packet; with this patch it reports none.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eventfs: Fix use-after-free in eventfs_remove_rec()<br /> <br /> eventfs_remove_rec() recursively removes the child at the current loop<br /> position. After the recursive call returns, list_for_each_entry() advances<br /> by reading list.next from the removed child.<br /> <br /> If free_ei() drops the final reference, release_ei() reuses the list/rcu<br /> union to queue an SRCU callback. The child may be freed before that read.<br /> The eventfs_mutex serializes list updates, but it does not keep the removed<br /> child alive or prevent the SRCU callback from running.<br /> <br /> Use list_for_each_entry_safe() to save the next sibling before recursively<br /> removing the current child.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: Fix use-after-free in cifs_try_adding_channels()<br /> <br /> cifs_try_adding_channels() takes a temporary reference to an interface<br /> before dropping iface_lock. If cifs_ses_add_channel() fails, it drops<br /> that reference and then increments iface-&gt;weight_fulfilled.<br /> <br /> A concurrent interface list refresh can remove the list reference while<br /> channel creation is in progress. In that case, the failure-path<br /> kref_put() releases the last reference and frees iface. Updating<br /> weight_fulfilled afterward then accesses freed memory.<br /> <br /> Increment weight_fulfilled before dropping the temporary reference,<br /> keeping iface alive for the final access.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: read le-&gt;link under the node lock in tipc_node_link_down()<br /> <br /> tipc_node_link_down() caches the link pointer before taking n-&gt;lock:<br /> <br /> struct tipc_link *l = le-&gt;link; /* unlocked */<br /> <br /> if (!l)<br /> return;<br /> tipc_node_write_lock(n);<br /> if (!tipc_link_is_establishing(l)) { /* deref l */<br /> ...<br /> tipc_link_reset(l); /* write into l */<br /> if (delete) {<br /> kfree(l);<br /> le-&gt;link = NULL;<br /> <br /> The delete=true caller frees that very object under n-&gt;lock, so the lock<br /> does not protect the cached pointer against it:<br /> <br /> - CPU A, delete=false: tipc_rcv() on TIPC_LINK_DOWN_EVT, or the link<br /> supervision timer via tipc_node_timeout(), reads l unlocked and then<br /> dereferences it under n-&gt;lock;<br /> - CPU B, delete=true: netlink TIPC_NL_BEARER_DISABLE -&gt; bearer_disable()<br /> -&gt; tipc_node_delete_links() -&gt; tipc_node_link_down(n, bearer_id, true)<br /> -&gt; kfree(l).<br /> <br /> The link is freed with plain kfree(), not kfree_rcu(), and for UDP bearers<br /> disable_media() only schedules the asynchronous cleanup_bearer() work, so<br /> its synchronize_net() runs after the links are already gone. An in-flight<br /> CPU A that has read l therefore dereferences freed memory once B frees it:<br /> a use-after-free read in tipc_link_is_establishing(), and a use-after-free<br /> write via tipc_link_reset() on the establishing branch.<br /> <br /> The following trace was captured on 7.2.0-rc5-00284-gaf39eb111ce6:<br /> <br /> BUG: KASAN: slab-use-after-free in tipc_link_is_establishing (net/tipc/link.c:285)<br /> Read of size 4 at addr ffff88802e2aa068 by task swapper/2/0<br /> tipc_link_is_establishing (net/tipc/link.c:285)<br /> tipc_node_link_down (net/tipc/node.c:1076)<br /> tipc_node_timeout (net/tipc/node.c:843)<br /> Allocated by task 9549:<br /> tipc_link_create (net/tipc/link.c:490)<br /> tipc_node_check_dest (net/tipc/node.c:1279)<br /> tipc_disc_rcv (net/tipc/discover.c:252)<br /> tipc_udp_recv (net/tipc/udp_media.c:389)<br /> Freed by task 9549:<br /> tipc_node_link_down (net/tipc/node.c:1084)<br /> tipc_node_delete_links (net/tipc/node.c:1320)<br /> bearer_disable (net/tipc/bearer.c:414)<br /> __tipc_nl_bearer_disable (net/tipc/bearer.c:992)<br /> <br /> Move the le-&gt;link read inside tipc_node_write_lock(), so it is serialised<br /> against the kfree() in the delete path. A racing teardown now either has<br /> not run yet, and we see a valid link, or has already run, and we see NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tls: don&amp;#39;t leave a full plaintext sk_msg ring unpushed<br /> <br /> When the copy path in tls_sw_sendmsg_locked() adds the fragment that fills<br /> the plaintext sk_msg ring, it does not set full_record, so the record is<br /> left full and unpushed. A later splice() then adds to an already full<br /> ring: sk_msg_page_add() has no fullness check of its own, so sg.end wraps<br /> onto sg.start and the ring appears empty. Fragments added after that<br /> overwrite live entries, and sg.size no longer matches what is reachable<br /> between sg.start and sg.end, so pushing the record runs the scatterwalk off<br /> the end of the scatterlist.<br /> <br /> An unprivileged user can trigger this on a loopback TCP socket with the<br /> "tls" ULP attached:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> RIP: 0010:memcpy_from_scatterwalk+0x32/0xc0<br /> Call Trace:<br /> skcipher_walk_next+0x1d1/0x2c0<br /> gcm_encrypt_aesni_avx+0x1e9/0x220<br /> bpf_exec_tx_verdict+0x3bb/0x860<br /> tls_sw_sendmsg+0xa1a/0xca0<br /> __sys_sendto+0x1da/0x1f0<br /> <br /> Set full_record in the copy path when the ring becomes full, and push a<br /> record that is already full on entry to the sendmsg loop.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tls: rx: restore msg_iter before TLS 1.3 optimistic retry<br /> <br /> tls_decrypt_sg() advances msg-&gt;msg_iter when it maps user pages for<br /> the optimistic TLS 1.3 zero-copy path. If the decrypted record turns<br /> out not to be unpadded application data, tls_decrypt_sw() retries into<br /> a kernel skb, but leaves the iterator advanced.<br /> <br /> The subsequent copy from the skb then writes decrypted bytes again at<br /> a later point in the caller iovecs while recvmsg() reports only the<br /> post-retry length. A TLS peer can trigger this after the receiver<br /> enables TLS_RX_EXPECT_NO_PAD.<br /> <br /> Revert the iterator by the number of bytes consumed by the optimistic<br /> mapping before retrying without zero-copy.<br /> <br /> Add a selftest which sends a TLS 1.3 control record with<br /> TLS_RX_EXPECT_NO_PAD enabled and verifies that recvmsg() does not<br /> overwrite later iovecs beyond the returned length.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: avoid refilling the RX queue after teardown<br /> <br /> Commit b917507e5ad9 ("vsock/virtio: stop workers during the .remove()")<br /> made the RX worker jump to its common exit when rx_run is clear. That<br /> exit still refills the RX queue when the buffer count is low, so work<br /> queued across virtio_vsock_vqs_del() can add buffers after the virtqueues<br /> have been deleted.<br /> <br /> BUG: KASAN: slab-use-after-free in virtqueue_add_sgs<br /> Read of size 4 by task kworker/0:1<br /> Workqueue: virtio_vsock virtio_transport_rx_work<br /> Call Trace:<br /> virtqueue_add_sgs (drivers/virtio/virtio_ring.c:2796)<br /> virtio_vsock_rx_fill (net/vmw_vsock/virtio_transport.c:332)<br /> virtio_transport_rx_work (net/vmw_vsock/virtio_transport.c:701)<br /> process_one_work (kernel/workqueue.c:3314)<br /> worker_thread (kernel/workqueue.c:3478)<br /> kthread (kernel/kthread.c:436)<br /> ret_from_fork (arch/x86/kernel/process.c:158)<br /> ret_from_fork_asm (arch/x86/entry/entry_64.S:245)<br /> ...<br /> Freed by task 141:<br /> kfree (mm/slub.c:6566)<br /> vp_del_vq (drivers/virtio/virtio_pci_common.c:259)<br /> vp_del_vqs (drivers/virtio/virtio_pci_common.c:285)<br /> virtio_vsock_freeze (net/vmw_vsock/virtio_transport.c:912)<br /> virtio_device_freeze (drivers/virtio/virtio.c:658)<br /> virtio_pci_freeze (drivers/virtio/virtio_pci_common.c:601)<br /> pci_pm_freeze (drivers/pci/pci-driver.c:1098)<br /> device_suspend (drivers/base/power/main.c:1968)<br /> Kernel panic - not syncing: KASAN: panic_on_warn set ...<br /> <br /> Jump to a no-refill exit when rx_run is clear, leaving the normal exit<br /> to replenish a running queue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Serialize accesses to the owner and mirror list with separate lock<br /> <br /> Interaction between KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM and<br /> KVM_CAP_VM_COPY_ENC_CONTEXT_FROM can cause two separate issues:<br /> <br /> - in sev_migrate_from(), when the destination KVM is a mirror, the mirror<br /> entry is moved from the source&amp;#39;s list to the owner&amp;#39;s mirror_vms list,<br /> without holding the owner&amp;#39;s lock unlike other writers of the owner&amp;#39;s<br /> mirror list (sev_vm_copy_enc_context_from(), sev_vm_destroy()).<br /> A concurrent COPY or destroy can race with sev_migrate_from() and<br /> corrupt the list.<br /> <br /> - In sev_vm_destroy(), the *owner* is still active and could receive<br /> concurrently a KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM that causes<br /> sev-&gt;enc_context_owner to change. In this case the incorrect VM<br /> receives kvm_put_kvm().<br /> <br /> The second issue needs particular care because the owner could disappear<br /> altogether (even though the race window is impossibly small) between<br /> reading it and locking it. There is thus no way to perform the checks<br /> under the owner lock without putting struct kvm under SLAB_TYPESAFE_BY_RCU<br /> (which would allow kvm_get_kvm_safe() under RCU critical section).<br /> <br /> It is much simpler to just use a global lock, since the critical<br /> sections are so small and the new lock is always a leaf lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> veth: fix skb length accounting after XDP frag adjustment<br /> <br /> veth exposes non-linear skb fragments through an xdp_buff. If an XDP<br /> program adjusts the fragment area, veth_xdp_rcv_skb() copies<br /> xdp_frags_size back to skb-&gt;data_len but leaves skb-&gt;len containing the<br /> old fragment contribution.<br /> <br /> After a fragment shrink, this makes skb_headlen() larger than the actual<br /> linear area. In the reproduced UDP receive path, __skb_datagram_iter()<br /> copied 1024 bytes past the actual linear tail to userspace, starting at<br /> struct skb_shared_info. The copied bytes included the affected skb&amp;#39;s<br /> nr_frags, xdp_frags_size, and a kernel pointer from<br /> skb_shinfo(skb)-&gt;frags[0]. Real packet data was displaced by the same<br /> amount and truncated at the end.<br /> <br /> Subtract the old data_len before replacing it and add the new data_len<br /> afterwards, keeping skb-&gt;len and skb-&gt;data_len synchronized.<br /> <br /> Additionally, bpf_xdp_pull_data() can advance data_end while leaving<br /> frags present. The skb is then still non-linear, so the old<br /> __skb_put(skb, off) triggers SKB_LINEAR_ASSERT().<br /> <br /> Use skb_set_tail_pointer() and update skb-&gt;len explicitly instead,<br /> following bpf_prog_run_generic_xdp(). Unlike __skb_put(),<br /> skb_set_tail_pointer() does not require a linear skb.<br /> <br /> A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened by<br /> 1024 bytes from its fragment area. Before the fix, all 10 runs produced<br /> corrupted payloads. After the fix, all 10 runs matched the expected<br /> payload exactly. A forced-tailroom reproducer also exercises<br /> bpf_xdp_pull_data() with frags still present; the old code triggers<br /> SKB_LINEAR_ASSERT(), while this fix passes 10/10 runs.