Vulnerabilities

A client can trigger excessive memory allocation by generating a lot of queries that are routed to an overloaded DoH backend, causing queries to accumulate into a buffer that will not be released until the end of the connection.

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 /> 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 /> 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 /> 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 /> 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: 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 /> 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 /> module: Fix kernel panic when a symbol st_shndx is out of bounds<br /> <br /> The module loader doesn&amp;#39;t check for bounds of the ELF section index in<br /> simplify_symbols():<br /> <br /> for (i = 1; i sh_size / sizeof(Elf_Sym); i++) {<br /> const char *name = info-&gt;strtab + sym[i].st_name;<br /> <br /> switch (sym[i].st_shndx) {<br /> case SHN_COMMON:<br /> <br /> [...]<br /> <br /> default:<br /> /* Divert to percpu allocation if a percpu var. */<br /> if (sym[i].st_shndx == info-&gt;index.pcpu)<br /> secbase = (unsigned long)mod_percpu(mod);<br /> else<br /> /** HERE --&gt; **/ secbase = info-&gt;sechdrs[sym[i].st_shndx].sh_addr;<br /> sym[i].st_value += secbase;<br /> break;<br /> }<br /> }<br /> <br /> A symbol with an out-of-bounds st_shndx value, for example 0xffff<br /> (known as SHN_XINDEX or SHN_HIRESERVE), may cause a kernel panic:<br /> <br /> BUG: unable to handle page fault for address: ...<br /> RIP: 0010:simplify_symbols+0x2b2/0x480<br /> ...<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> This can happen when module ELF is legitimately using SHN_XINDEX or<br /> when it is corrupted.<br /> <br /> Add a bounds check in simplify_symbols() to validate that st_shndx is<br /> within the valid range before using it.<br /> <br /> This issue was discovered due to a bug in llvm-objcopy, see relevant<br /> discussion for details [1].<br /> <br /> [1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: apple: avoid memory leak in apple_report_fixup()<br /> <br /> The apple_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.