Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack: defer invalid log until after unlock<br /> <br /> TCP and SCTP conntrack paths can emit invalid-packet logs while ct-&gt;lock<br /> is still held.<br /> <br /> When invalid logging is routed to nfnetlink_log and conntrack export is<br /> enabled, the log path can re-enter conntrack netlink glue and dump the<br /> same conntrack again. Protocol attribute dumping may take ct-&gt;lock, so<br /> logging while holding that lock can deadlock.<br /> <br /> Defer the TCP invalid logs by storing only the minimal log context while<br /> ct-&gt;lock is held and emitting the log after unlocking. Also make the TCP<br /> timeout-lowering invalid path return whether a log is needed, then emit<br /> that log after unlocking.<br /> <br /> Do the same for the SCTP invalid state-transition log that can be reached<br /> while ct-&gt;lock is held.<br /> <br /> Add a lockdep assertion to nf_ct_l4proto_log_invalid() so future callers<br /> that log invalid conntracks while holding ct-&gt;lock are caught outside TCP<br /> and SCTP as well.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NTB: ntb_netdev: Preserve RX queue depth on allocation failure<br /> <br /> ntb_netdev_rx_handler() hands the received skb to the network stack<br /> before allocating its replacement. If the allocation fails, nothing is<br /> reposted. Every failure therefore takes one buffer out of the RX queue<br /> while the interface remains up, and enough failures eventually stall<br /> reception.<br /> <br /> A retry path could refill the queue later, but ntb_netdev has none.<br /> Allocate the replacement first instead. If that fails, drop the packet<br /> and repost the same skb. This keeps the queue full and lets packet<br /> delivery resume as soon as memory is available again.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/x25: fix use-after-free of the socket by its timers<br /> <br /> The x25 timers are armed with mod_timer() and cancelled with<br /> timer_delete(), so a pending timer holds no reference on the socket and a<br /> cancel does not wait for a callback already running on another CPU.<br /> <br /> x25_heartbeat_expiry() also rearms unconditionally, so it can reinstall<br /> sk-&gt;sk_timer after __x25_destroy_socket() has passed its cancel point.<br /> The following __sock_put() frees the socket while the timer is still<br /> queued, and the next expiry uses freed memory. KASAN reports a<br /> slab-use-after-free on the kmalloc-2k object freed by close().<br /> <br /> timer_delete_sync() cannot be used here: x25_heartbeat_expiry() and<br /> x25_timer_expiry() both reach the cancels from inside the timer they<br /> would wait on, through __x25_destroy_socket() and x25_disconnect().<br /> <br /> Arm the timers with sk_reset_timer() and cancel them with sk_stop_timer()<br /> so that an armed timer owns a reference, and release it in both expiry<br /> handlers. Rearm the heartbeat only while sk_hashed(sk) is still true,<br /> since __x25_destroy_socket() unlinks the socket before dropping it. Arm<br /> the deferred destroy timer the same way and drop its reference in<br /> x25_destroy_timer().<br /> <br /> Reproduced on net with KASAN, with the heartbeat period shortened so the<br /> window recurs. With this patch the reproducer no longer triggers a<br /> report and /proc/net/x25 drains.<br /> <br /> Discovered by XBOW, triaged by Baul Lee

*** 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 /> vsock/virtio: read virtqueues under worker locks<br /> <br /> Commit bd50c5dc182b ("vsock/virtio: add support for device<br /> suspend/resume") made the *_run flags transition from false to true when<br /> restore installs replacement virtqueues. The RX, TX and event workers<br /> read their virtqueue before locking and checking the corresponding flag,<br /> so a worker delayed across freeze and restore can observe the replacement<br /> queue&amp;#39;s running state while retaining a pointer to the deleted queue.<br /> <br /> Read each virtqueue under its mutex after checking the run flag, keeping<br /> the pointer and state in the same queue generation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: do not arm the ageing timer on a device that is down<br /> <br /> vxlan_changelink() arms vxlan-&gt;age_timer whenever the requested ageing<br /> interval differs from the configured one:<br /> <br /> if (conf.age_interval != vxlan-&gt;cfg.age_interval)<br /> mod_timer(&amp;vxlan-&gt;age_timer, jiffies);<br /> <br /> There is no netif_running() test, so the timer is armed even on a device<br /> that was never brought up. The only synchronous cancel in the driver is<br /> the timer_delete_sync() in vxlan_stop(), which is .ndo_stop.<br /> netif_close_many() drops devices without IFF_UP before<br /> __dev_close_many() runs, so that cancel is skipped for such a device.<br /> <br /> vxlan_setup() sets dev-&gt;needs_free_netdev = true and age_timer is a<br /> member of struct vxlan_dev, so free_netdev() releases the allocation the<br /> timer lives in while it is still queued on a timer_base.<br /> expire_timers() unlinks the entry before it loads timer-&gt;function, so<br /> the timer core writes through the freed object&amp;#39;s list pointers:<br /> <br /> BUG: KASAN: slab-use-after-free in __run_timers+0x208/0x654<br /> Write of size 8 at addr ffff00001adace68 by task true/192<br /> __asan_store8+0x84/0xac<br /> __run_timers+0x208/0x654<br /> run_timer_softirq+0x154/0x18c<br /> Allocated by task 189:<br /> alloc_netdev_mqs+0x64/0x720<br /> rtnl_create_link+0x4ac/0x520<br /> rtnl_newlink+0x758/0xd00<br /> Freed by task 191:<br /> netdev_release+0x40/0x58<br /> netdev_run_todo+0x4a4/0x8c0<br /> rtnl_dellink+0x200/0x4e8<br /> <br /> The rtnl operations involved are netns-scoped, so an unprivileged user<br /> can perform them in a new user and network namespace.<br /> <br /> Arming the timer on a down device never had an effect: vxlan_cleanup()<br /> returns early on !netif_running(), and vxlan_open() arms the timer for<br /> any non-zero interval once the device is brought up. Add the missing<br /> test.<br /> <br /> Discovered by XBOW, triaged by Baul Lee

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xdp: reject clones that overrun skb_shared_info tailroom<br /> <br /> xdpf_clone() clones broadcast copies into a single page and sets<br /> frame_sz to PAGE_SIZE. __xdp_build_skb_from_frame() later treats that<br /> page like a normal XDP frame and expects the usual skb_shared_info<br /> tailroom at the end of the buffer.<br /> <br /> The current check only rejects frames whose linear xdp_frame header,<br /> headroom, and packet data exceed PAGE_SIZE. A source frame backed by a<br /> larger allocation can still satisfy that check while extending into the<br /> clone&amp;#39;s required shared-info area. When such a clone is converted back<br /> into an skb, build_skb_around() places skb_shared_info over live packet<br /> bytes and later writes can corrupt XDP return metadata.<br /> <br /> Reject clones unless their linear area fits inside<br /> SKB_WITH_OVERHEAD(PAGE_SIZE), matching the tailroom requirement already<br /> enforced by the XDP-to-skb conversion path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dibs: initialise dibs-&gt;lock in dibs_dev_alloc()<br /> <br /> dibs-&gt;lock is initialised by dibs_dev_add(), but a dibs device can<br /> already take interrupts before that call: ism_probe() runs<br /> ism_dev_init(), and hence request_irq(), before it calls<br /> dibs_dev_add(). No client can have registered a dmb at that point, so<br /> no dmb interrupt can occur, but a GID event interrupt can, and<br /> ism_handle_irq() takes dibs-&gt;lock unconditionally on entry, before it<br /> inspects anything else.<br /> <br /> Initialise the lock in dibs_dev_alloc() instead, so that it is valid as<br /> soon as a driver can publish the device to its interrupt handler.

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