Vulnerabilities

A client can trigger excessive memory allocation by generating a lot of errors responses over a single DoQ and DoH3 connection, as some resources were not properly released until the end of the connection.

An attacker can create a large number of concurrent DoQ or DoH3 connections, causing unlimited memory allocation in DNSdist and leading to a denial of service. DOQ and DoH3 are disabled by default.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: magicmouse: avoid memory leak in magicmouse_report_fixup()<br /> <br /> The magicmouse_report_fixup() function was returning a<br /> newly kmemdup()-allocated buffer, but never freeing it.<br /> <br /> The caller of report_fixup() does not take ownership of the returned<br /> pointer, but it *is* permitted to return a sub-portion of the input<br /> rdesc, whose lifetime is managed by the caller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: ensure we&amp;#39;re polling a polled queue<br /> <br /> A user can change the polled queue count at run time. There&amp;#39;s a brief<br /> window during a reset where a hipri task may try to poll that queue<br /> before the block layer has updated the queue maps, which would race with<br /> the now interrupt driven queue and may cause double completions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: asus: avoid memory leak in asus_report_fixup()<br /> <br /> The asus_report_fixup() function was returning a newly allocated<br /> kmemdup()-allocated buffer, but never freeing it. Switch to<br /> devm_kzalloc() to ensure the memory is managed and freed automatically<br /> when the device is removed.<br /> <br /> The caller of report_fixup() does not take ownership of the returned<br /> pointer, but it is permitted to return a pointer whose lifetime is at<br /> least that of the input buffer.<br /> <br /> Also fix a harmless out-of-bounds read by copying only the original<br /> descriptor size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix undefined behavior in interpreter sdiv/smod for INT_MIN<br /> <br /> The BPF interpreter&amp;#39;s signed 32-bit division and modulo handlers use<br /> the kernel abs() macro on s32 operands. The abs() macro documentation<br /> (include/linux/math.h) explicitly states the result is undefined when<br /> the input is the type minimum. When DST contains S32_MIN (0x80000000),<br /> abs((s32)DST) triggers undefined behavior and returns S32_MIN unchanged<br /> on arm64/x86. This value is then sign-extended to u64 as<br /> 0xFFFFFFFF80000000, causing do_div() to compute the wrong result.<br /> <br /> The verifier&amp;#39;s abstract interpretation (scalar32_min_max_sdiv) computes<br /> the mathematically correct result for range tracking, creating a<br /> verifier/interpreter mismatch that can be exploited for out-of-bounds<br /> map value access.<br /> <br /> Introduce abs_s32() which handles S32_MIN correctly by casting to u32<br /> before negating, avoiding signed overflow entirely. Replace all 8<br /> abs((s32)...) call sites in the interpreter&amp;#39;s sdiv32/smod32 handlers.<br /> <br /> s32 is the only affected case -- the s64 division/modulo handlers do<br /> not use abs().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix exception exit lock checking for subprogs<br /> <br /> process_bpf_exit_full() passes check_lock = !curframe to<br /> check_resource_leak(), which is false in cases when bpf_throw() is<br /> called from a static subprog. This makes check_resource_leak() to skip<br /> validation of active_rcu_locks, active_preempt_locks, and<br /> active_irq_id on exception exits from subprogs.<br /> <br /> At runtime bpf_throw() unwinds the stack via ORC without releasing any<br /> user-acquired locks, which may cause various issues as the result.<br /> <br /> Fix by setting check_lock = true for exception exits regardless of<br /> curframe, since exceptions bypass all intermediate frame<br /> cleanup. Update the error message prefix to "bpf_throw" for exception<br /> exits to distinguish them from normal BPF_EXIT.<br /> <br /> Fix reject_subprog_with_rcu_read_lock test which was previously<br /> passing for the wrong reason. Test program returned directly from the<br /> subprog call without closing the RCU section, so the error was<br /> triggered by the unclosed RCU lock on normal exit, not by<br /> bpf_throw. Update __msg annotations for affected tests to match the<br /> new "bpf_throw" error prefix.<br /> <br /> The spin_lock case is not affected because they are already checked [1]<br /> at the call site in do_check_insn() before bpf_throw can run.<br /> <br /> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/verifier.c?h=v7.0-rc4#n21098

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: platform: use generic driver_override infrastructure<br /> <br /> When a driver is probed through __driver_attach(), the bus&amp;#39; match()<br /> callback is called without the device lock held, thus accessing the<br /> driver_override field without a lock, which can cause a UAF.<br /> <br /> Fix this by using the driver-core driver_override infrastructure taking<br /> care of proper locking internally.<br /> <br /> Note that calling match() from __driver_attach() without the device lock<br /> held is intentional. [1]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: prevent policy_hthresh.work from racing with netns teardown<br /> <br /> A XFRM_MSG_NEWSPDINFO request can queue the per-net work item<br /> policy_hthresh.work onto the system workqueue.<br /> <br /> The queued callback, xfrm_hash_rebuild(), retrieves the enclosing<br /> struct net via container_of(). If the net namespace is torn down<br /> before that work runs, the associated struct net may already have<br /> been freed, and xfrm_hash_rebuild() may then dereference stale memory.<br /> <br /> xfrm_policy_fini() already flushes policy_hash_work during teardown,<br /> but it does not synchronize policy_hthresh.work.<br /> <br /> Synchronize policy_hthresh.work in xfrm_policy_fini() as well, so the<br /> queued work cannot outlive the net namespace teardown and access a<br /> freed struct net.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: iptfs: fix skb_put() panic on non-linear skb during reassembly<br /> <br /> In iptfs_reassem_cont(), IP-TFS attempts to append data to the new inner<br /> packet &amp;#39;newskb&amp;#39; that is being reassembled. First a zero-copy approach is<br /> tried if it succeeds then newskb becomes non-linear.<br /> <br /> When a subsequent fragment in the same datagram does not meet the<br /> fast-path conditions, a memory copy is performed. It calls skb_put() to<br /> append the data and as newskb is non-linear it triggers<br /> SKB_LINEAR_ASSERT check.<br /> <br /> Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> [...]<br /> RIP: 0010:skb_put+0x3c/0x40<br /> [...]<br /> Call Trace:<br /> <br /> iptfs_reassem_cont+0x1ab/0x5e0 [xfrm_iptfs]<br /> iptfs_input_ordered+0x2af/0x380 [xfrm_iptfs]<br /> iptfs_input+0x122/0x3e0 [xfrm_iptfs]<br /> xfrm_input+0x91e/0x1a50<br /> xfrm4_esp_rcv+0x3a/0x110<br /> ip_protocol_deliver_rcu+0x1d7/0x1f0<br /> ip_local_deliver_finish+0xbe/0x1e0<br /> __netif_receive_skb_core.constprop.0+0xb56/0x1120<br /> __netif_receive_skb_list_core+0x133/0x2b0<br /> netif_receive_skb_list_internal+0x1ff/0x3f0<br /> napi_complete_done+0x81/0x220<br /> virtnet_poll+0x9d6/0x116e [virtio_net]<br /> __napi_poll.constprop.0+0x2b/0x270<br /> net_rx_action+0x162/0x360<br /> handle_softirqs+0xdc/0x510<br /> __irq_exit_rcu+0xe7/0x110<br /> irq_exit_rcu+0xe/0x20<br /> common_interrupt+0x85/0xa0<br /> <br /> <br /> <br /> Fix this by checking if the skb is non-linear. If it is, linearize it by<br /> calling skb_linearize(). As the initial allocation of newskb originally<br /> reserved enough tailroom for the entire reassembled packet we do not<br /> need to check if we have enough tailroom or extend it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> esp: fix skb leak with espintcp and async crypto<br /> <br /> When the TX queue for espintcp is full, esp_output_tail_tcp will<br /> return an error and not free the skb, because with synchronous crypto,<br /> the common xfrm output code will drop the packet for us.<br /> <br /> With async crypto (esp_output_done), we need to drop the skb when<br /> esp_output_tail_tcp returns an error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: set BTRFS_ROOT_ORPHAN_CLEANUP during subvol create<br /> <br /> We have recently observed a number of subvolumes with broken dentries.<br /> ls-ing the parent dir looks like:<br /> <br /> drwxrwxrwt 1 root root 16 Jan 23 16:49 .<br /> drwxr-xr-x 1 root root 24 Jan 23 16:48 ..<br /> d????????? ? ? ? ? ? broken_subvol<br /> <br /> and similarly stat-ing the file fails.<br /> <br /> In this state, deleting the subvol fails with ENOENT, but attempting to<br /> create a new file or subvol over it errors out with EEXIST and even<br /> aborts the fs. Which leaves us a bit stuck.<br /> <br /> dmesg contains a single notable error message reading:<br /> "could not do orphan cleanup -2"<br /> <br /> 2 is ENOENT and the error comes from the failure handling path of<br /> btrfs_orphan_cleanup(), with the stack leading back up to<br /> btrfs_lookup().<br /> <br /> btrfs_lookup<br /> btrfs_lookup_dentry<br /> btrfs_orphan_cleanup // prints that message and returns -ENOENT<br /> <br /> After some detailed inspection of the internal state, it became clear<br /> that:<br /> - there are no orphan items for the subvol<br /> - the subvol is otherwise healthy looking, it is not half-deleted or<br /> anything, there is no drop progress, etc.<br /> - the subvol was created a while ago and does the meaningful first<br /> btrfs_orphan_cleanup() call that sets BTRFS_ROOT_ORPHAN_CLEANUP much<br /> later.<br /> - after btrfs_orphan_cleanup() fails, btrfs_lookup_dentry() returns -ENOENT,<br /> which results in a negative dentry for the subvolume via<br /> d_splice_alias(NULL, dentry), leading to the observed behavior. The<br /> bug can be mitigated by dropping the dentry cache, at which point we<br /> can successfully delete the subvolume if we want.<br /> <br /> i.e.,<br /> btrfs_lookup()<br /> btrfs_lookup_dentry()<br /> if (!sb_rdonly(inode-&gt;vfs_inode)-&gt;vfs_inode)<br /> btrfs_orphan_cleanup(sub_root)<br /> test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP)<br /> btrfs_search_slot() // finds orphan item for inode N<br /> ...<br /> prints "could not do orphan cleanup -2"<br /> if (inode == ERR_PTR(-ENOENT))<br /> inode = NULL;<br /> return d_splice_alias(NULL, dentry) // NEGATIVE DENTRY for valid subvolume<br /> <br /> btrfs_orphan_cleanup() does test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP)<br /> on the root when it runs, so it cannot run more than once on a given<br /> root, so something else must run concurrently. However, the obvious<br /> routes to deleting an orphan when nlinks goes to 0 should not be able to<br /> run without first doing a lookup into the subvolume, which should run<br /> btrfs_orphan_cleanup() and set the bit.<br /> <br /> The final important observation is that create_subvol() calls<br /> d_instantiate_new() but does not set BTRFS_ROOT_ORPHAN_CLEANUP, so if<br /> the dentry cache gets dropped, the next lookup into the subvolume will<br /> make a real call into btrfs_orphan_cleanup() for the first time. This<br /> opens up the possibility of concurrently deleting the inode/orphan items<br /> but most typical evict() paths will be holding a reference on the parent<br /> dentry (child dentry holds parent-&gt;d_lockref.count via dget in<br /> d_alloc(), released in __dentry_kill()) and prevent the parent from<br /> being removed from the dentry cache.<br /> <br /> The one exception is delayed iputs. Ordered extent creation calls<br /> igrab() on the inode. If the file is unlinked and closed while those<br /> refs are held, iput() in __dentry_kill() decrements i_count but does<br /> not trigger eviction (i_count &gt; 0). The child dentry is freed and the<br /> subvol dentry&amp;#39;s d_lockref.count drops to 0, making it evictable while<br /> the inode is still alive.<br /> <br /> Since there are two races (the race between writeback and unlink and<br /> the race between lookup and delayed iputs), and there are too many moving<br /> parts, the following three diagrams show the complete picture.<br /> (Only the second and third are races)<br /> <br /> Phase 1:<br /> Create Subvol in dentry cache without BTRFS_ROOT_ORPHAN_CLEANUP set<br /> <br /> btrfs_mksubvol()<br /> lookup_one_len()<br /> __lookup_slow()<br /> d_alloc_parallel()<br /> __d_alloc() // d_lockref.count = 1<br /> create_subvol(dentry)<br /> // doesn&amp;#39;t touch the bit..<br /> d_instantiate_new(dentry, inode) // dentry in cache with d_lockref.c<br /> ---truncated---