Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp: do not accept non-tunnel GSO skbs landing in a tunnel<br /> <br /> When rx-udp-gro-forwarding is enabled UDP packets might be GROed when<br /> being forwarded. If such packets might land in a tunnel this can cause<br /> various issues and udp_gro_receive makes sure this isn&amp;#39;t the case by<br /> looking for a matching socket. This is performed in<br /> udp4/6_gro_lookup_skb but only in the current netns. This is an issue<br /> with tunneled packets when the endpoint is in another netns. In such<br /> cases the packets will be GROed at the UDP level, which leads to various<br /> issues later on. The same thing can happen with rx-gro-list.<br /> <br /> We saw this with geneve packets being GROed at the UDP level. In such<br /> case gso_size is set; later the packet goes through the geneve rx path,<br /> the geneve header is pulled, the offset are adjusted and frag_list skbs<br /> are not adjusted with regard to geneve. When those skbs hit<br /> skb_fragment, it will misbehave. Different outcomes are possible<br /> depending on what the GROed skbs look like; from corrupted packets to<br /> kernel crashes.<br /> <br /> One example is a BUG_ON[1] triggered in skb_segment while processing the<br /> frag_list. Because gso_size is wrong (geneve header was pulled)<br /> skb_segment thinks there is "geneve header size" of data in frag_list,<br /> although it&amp;#39;s in fact the next packet. The BUG_ON itself has nothing to<br /> do with the issue. This is only one of the potential issues.<br /> <br /> Looking up for a matching socket in udp_gro_receive is fragile: the<br /> lookup could be extended to all netns (not speaking about performances)<br /> but nothing prevents those packets from being modified in between and we<br /> could still not find a matching socket. It&amp;#39;s OK to keep the current<br /> logic there as it should cover most cases but we also need to make sure<br /> we handle tunnel packets being GROed too early.<br /> <br /> This is done by extending the checks in udp_unexpected_gso: GSO packets<br /> lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel must<br /> be segmented.<br /> <br /> [1] kernel BUG at net/core/skbuff.c:4408!<br /> RIP: 0010:skb_segment+0xd2a/0xf70<br /> __udp_gso_segment+0xaa/0x560

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of: dynamic: Synchronize of_changeset_destroy() with the devlink removals<br /> <br /> In the following sequence:<br /> 1) of_platform_depopulate()<br /> 2) of_overlay_remove()<br /> <br /> During the step 1, devices are destroyed and devlinks are removed.<br /> During the step 2, OF nodes are destroyed but<br /> __of_changeset_entry_destroy() can raise warnings related to missing<br /> of_node_put():<br /> ERROR: memory leak, expected refcount 1 instead of 2 ...<br /> <br /> Indeed, during the devlink removals performed at step 1, the removal<br /> itself releasing the device (and the attached of_node) is done by a job<br /> queued in a workqueue and so, it is done asynchronously with respect to<br /> function calls.<br /> When the warning is present, of_node_put() will be called but wrongly<br /> too late from the workqueue job.<br /> <br /> In order to be sure that any ongoing devlink removals are done before<br /> the of_node destruction, synchronize the of_changeset_destroy() with the<br /> devlink removals.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix potential UAF in smb2_is_valid_oplock_break()<br /> <br /> Skip sessions that are being teared down (status == SES_EXITING) to<br /> avoid UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix potential UAF in cifs_stats_proc_write()<br /> <br /> Skip sessions that are being teared down (status == SES_EXITING) to<br /> avoid UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/secretmem: fix GUP-fast succeeding on secretmem folios<br /> <br /> folio_is_secretmem() currently relies on secretmem folios being LRU<br /> folios, to save some cycles.<br /> <br /> However, folios might reside in a folio batch without the LRU flag set, or<br /> temporarily have their LRU flag cleared. Consequently, the LRU flag is<br /> unreliable for this purpose.<br /> <br /> In particular, this is the case when secretmem_fault() allocates a fresh<br /> page and calls filemap_add_folio()-&gt;folio_add_lru(). The folio might be<br /> added to the per-cpu folio batch and won&amp;#39;t get the LRU flag set until the<br /> batch was drained using e.g., lru_add_drain().<br /> <br /> Consequently, folio_is_secretmem() might not detect secretmem folios and<br /> GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel<br /> when we would later try reading/writing to the folio, because the folio<br /> has been unmapped from the directmap.<br /> <br /> Fix it by removing that unreliable check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Fix vector state restore in rt_sigreturn()<br /> <br /> The RISC-V Vector specification states in "Appendix D: Calling<br /> Convention for Vector State" [1] that "Executing a system call causes<br /> all caller-saved vector registers (v0-v31, vl, vtype) and vstart to<br /> become unspecified.". In the RISC-V kernel this is called "discarding<br /> the vstate".<br /> <br /> Returning from a signal handler via the rt_sigreturn() syscall, vector<br /> discard is also performed. However, this is not an issue since the<br /> vector state should be restored from the sigcontext, and therefore not<br /> care about the vector discard.<br /> <br /> The "live state" is the actual vector register in the running context,<br /> and the "vstate" is the vector state of the task. A dirty live state,<br /> means that the vstate and live state are not in synch.<br /> <br /> When vectorized user_from_copy() was introduced, an bug sneaked in at<br /> the restoration code, related to the discard of the live state.<br /> <br /> An example when this go wrong:<br /> <br /> 1. A userland application is executing vector code<br /> 2. The application receives a signal, and the signal handler is<br /> entered.<br /> 3. The application returns from the signal handler, using the<br /> rt_sigreturn() syscall.<br /> 4. The live vector state is discarded upon entering the<br /> rt_sigreturn(), and the live state is marked as "dirty", indicating<br /> that the live state need to be synchronized with the current<br /> vstate.<br /> 5. rt_sigreturn() restores the vstate, except the Vector registers,<br /> from the sigcontext<br /> 6. rt_sigreturn() restores the Vector registers, from the sigcontext,<br /> and now the vectorized user_from_copy() is used. The dirty live<br /> state from the discard is saved to the vstate, making the vstate<br /> corrupt.<br /> 7. rt_sigreturn() returns to the application, which crashes due to<br /> corrupted vstate.<br /> <br /> Note that the vectorized user_from_copy() is invoked depending on the<br /> value of CONFIG_RISCV_ISA_V_UCOPY_THRESHOLD. Default is 768, which<br /> means that vlen has to be larger than 128b for this bug to trigger.<br /> <br /> The fix is simply to mark the live state as non-dirty/clean prior<br /> performing the vstate restore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> aio: Fix null ptr deref in aio_complete() wakeup<br /> <br /> list_del_init_careful() needs to be the last access to the wait queue<br /> entry - it effectively unlocks access.<br /> <br /> Previously, finish_wait() would see the empty list head and skip taking<br /> the lock, and then we&amp;#39;d return - but the completion path would still<br /> attempt to do the wakeup after the task_struct pointer had been<br /> overwritten.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/coco: Require seeding RNG with RDRAND on CoCo systems<br /> <br /> There are few uses of CoCo that don&amp;#39;t rely on working cryptography and<br /> hence a working RNG. Unfortunately, the CoCo threat model means that the<br /> VM host cannot be trusted and may actively work against guests to<br /> extract secrets or manipulate computation. Since a malicious host can<br /> modify or observe nearly all inputs to guests, the only remaining source<br /> of entropy for CoCo guests is RDRAND.<br /> <br /> If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole<br /> is meant to gracefully continue on gathering entropy from other sources,<br /> but since there aren&amp;#39;t other sources on CoCo, this is catastrophic.<br /> This is mostly a concern at boot time when initially seeding the RNG, as<br /> after that the consequences of a broken RDRAND are much more<br /> theoretical.<br /> <br /> So, try at boot to seed the RNG using 256 bits of RDRAND output. If this<br /> fails, panic(). This will also trigger if the system is booted without<br /> RDRAND, as RDRAND is essential for a safe CoCo boot.<br /> <br /> Add this deliberately to be "just a CoCo x86 driver feature" and not<br /> part of the RNG itself. Many device drivers and platforms have some<br /> desire to contribute something to the RNG, and add_device_randomness()<br /> is specifically meant for this purpose.<br /> <br /> Any driver can call it with seed data of any quality, or even garbage<br /> quality, and it can only possibly make the quality of the RNG better or<br /> have no effect, but can never make it worse.<br /> <br /> Rather than trying to build something into the core of the RNG, consider<br /> the particular CoCo issue just a CoCo issue, and therefore separate it<br /> all out into driver (well, arch/platform) code.<br /> <br /> [ bp: Massage commit message. ]

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix potential UAF in cifs_stats_proc_show()<br /> <br /> Skip sessions that are being teared down (status == SES_EXITING) to<br /> avoid UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm/pat: fix VM_PAT handling in COW mappings<br /> <br /> PAT handling won&amp;#39;t do the right thing in COW mappings: the first PTE (or,<br /> in fact, all PTEs) can be replaced during write faults to point at anon<br /> folios. Reliably recovering the correct PFN and cachemode using<br /> follow_phys() from PTEs will not work in COW mappings.<br /> <br /> Using follow_phys(), we might just get the address+protection of the anon<br /> folio (which is very wrong), or fail on swap/nonswap entries, failing<br /> follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and<br /> track_pfn_copy(), not properly calling free_pfn_range().<br /> <br /> In free_pfn_range(), we either wouldn&amp;#39;t call memtype_free() or would call<br /> it with the wrong range, possibly leaking memory.<br /> <br /> To fix that, let&amp;#39;s update follow_phys() to refuse returning anon folios,<br /> and fallback to using the stored PFN inside vma-&gt;vm_pgoff for COW mappings<br /> if we run into that.<br /> <br /> We will now properly handle untrack_pfn() with COW mappings, where we<br /> don&amp;#39;t need the cachemode. We&amp;#39;ll have to fail fork()-&gt;track_pfn_copy() if<br /> the first page was replaced by an anon folio, though: we&amp;#39;d have to store<br /> the cachemode in the VMA to make this work, likely growing the VMA size.<br /> <br /> For now, lets keep it simple and let track_pfn_copy() just fail in that<br /> case: it would have failed in the past with swap/nonswap entries already,<br /> and it would have done the wrong thing with anon folios.<br /> <br /> Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():<br /> <br /> <br /> #include <br /> #include <br /> #include <br /> #include <br /> <br /> int main(void)<br /> {<br /> struct io_uring_params p = {};<br /> int ring_fd;<br /> size_t size;<br /> char *map;<br /> <br /> ring_fd = io_uring_setup(1, &amp;p);<br /> if (ring_fd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: process: Fix kernel gp leakage<br /> <br /> childregs represents the registers which are active for the new thread<br /> in user context. For a kernel thread, childregs-&gt;gp is never used since<br /> the kernel gp is not touched by switch_to. For a user mode helper, the<br /> gp value can be observed in user space after execve or possibly by other<br /> means.<br /> <br /> [From the email thread]<br /> <br /> The /* Kernel thread */ comment is somewhat inaccurate in that it is also used<br /> for user_mode_helper threads, which exec a user process, e.g. /sbin/init or<br /> when /proc/sys/kernel/core_pattern is a pipe. Such threads do not have<br /> PF_KTHREAD set and are valid targets for ptrace etc. even before they exec.<br /> <br /> childregs is the *user* context during syscall execution and it is observable<br /> from userspace in at least five ways:<br /> <br /> 1. kernel_execve does not currently clear integer registers, so the starting<br /> register state for PID 1 and other user processes started by the kernel has<br /> sp = user stack, gp = kernel __global_pointer$, all other integer registers<br /> zeroed by the memset in the patch comment.<br /> <br /> This is a bug in its own right, but I&amp;#39;m unwilling to bet that it is the only<br /> way to exploit the issue addressed by this patch.<br /> <br /> 2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread<br /> before it execs, but ptrace requires SIGSTOP to be delivered which can only<br /> happen at user/kernel boundaries.<br /> <br /> 3. /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for<br /> user_mode_helpers before the exec completes, but gp is not one of the<br /> registers it returns.<br /> <br /> 4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel<br /> addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses<br /> are also exposed via PERF_SAMPLE_REGS_USER which is permitted under<br /> LOCKDOWN_PERF. I have not attempted to write exploit code.<br /> <br /> 5. Much of the tracing infrastructure allows access to user registers. I have<br /> not attempted to determine which forms of tracing allow access to user<br /> registers without already allowing access to kernel registers.