Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fsnotify: prevent mark additions during connector teardown<br /> <br /> fsnotify_destroy_marks() keeps a reference to its current mark while it<br /> drops conn-&gt;lock to destroy the mark. This stabilizes the forward-walk<br /> cursor, but does not prevent a new mark from being inserted before it.<br /> For example, an inotify watch re-added after IN_IGNORED sorts before the<br /> old, detached mark for the same group. The walk can miss the replacement<br /> and then detach the entire connector from the object.<br /> <br /> The replacement is still on its group&amp;#39;s marks_list and, for inotify, in<br /> the watch IDR. The group mutex no longer protects the connector&amp;#39;s object<br /> from disappearing. An unprivileged fdinfo read racing the final detach<br /> can consequently call igrab(NULL):<br /> <br /> BUG: KASAN: null-ptr-deref in igrab+0x24/0x100<br /> Write of size 4 at addr 0000000000000148<br /> Call Trace:<br /> igrab+0x24/0x100<br /> inotify_show_fdinfo+0x1dc/0x5e0<br /> seq_show+0x397/0x690<br /> <br /> Set a DESTROYING flag under conn-&gt;lock before starting the walk, and<br /> reject new marks on that connector with -ENOENT. The existing add-mark<br /> error paths undo the temporary group-list entry and the backend&amp;#39;s watch<br /> allocation. Do not wait for teardown while holding the group mutex,<br /> which the destroyer needs. Once the old connector is detached, an add<br /> can install a fresh connector as before.<br /> <br /> This closes the insertion race for all object types using the common<br /> connector teardown, without changing the mark reference or SRCU lifetime<br /> rules.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nVMX: Reset MMU back to the root MMU if loading L2 state fails for !VM-Entry<br /> <br /> Reset the vCPU&amp;#39;s MMU pointer back to the root MMU if loading L2 state fails<br /> in the "not from VM-Entry" case, i.e. when emulating RSM or handling<br /> KVM_SET_NESTED_STATE. Failure to unwind the MMU pointer results in KVM<br /> trying to run L1 with a nested MMU, and is especially problematic if the<br /> vCPU manages to free its nested state before the VM crashes. Constructing<br /> the root for a nested EPT MMU goes through vmcs12, which is dynamically<br /> allocated/freed when nVMX is enabled/disabled. And so if the nested state<br /> is freed with the MMU still pointing at the nested MMU, KVM will hit a NULL<br /> pointer deref when attempting to get L1=&gt;L2 EPTP.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000078<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 114a2d067 P4D 111743067 PUD 11141f067 PMD 0<br /> Oops: Oops: 0000 [#1] SMP<br /> CPU: 20 UID: 1000 PID: 1272 Comm: nested_tdp_faul Not tainted 7.3.0-rc4-8c89f11d1a99b-sink-vm #1914 PREEMPTLAZY<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:nested_ept_get_eptp+0xb/0x10 [kvm_intel]<br /> Call Trace:<br /> <br /> kvm_mmu_load+0xcd/0x870 [kvm]<br /> kvm_arch_vcpu_ioctl_run+0x18f5/0x1f80 [kvm]<br /> kvm_vcpu_ioctl+0x2c7/0x970 [kvm]<br /> __x64_sys_ioctl+0x90/0xd0<br /> do_syscall_64+0x9c/0x4d0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x47491b<br /> <br /> Modules linked in: kvm_intel kvm irqbypass<br /> CR2: 0000000000000078<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:nested_ept_get_eptp+0xb/0x10 [kvm_intel]<br /> <br /> [sean: write changelog]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SEV: Fix page dirtying in sev_gmem_post_populate()<br /> <br /> set_page_dirty() requires that the caller holds some kind of lock to<br /> ensure that the page&amp;#39;s mapping does not concurrently go away.<br /> That is not the case for a random page we got from get_user_pages_fast(),<br /> so use set_page_dirty_lock().<br /> <br /> [sean: tag for stable]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/kvm: Don&amp;#39;t consume async #PF flags on a kernel #PF in NMI context<br /> <br /> An async #PF "page not present" event arrives through the #PF vector,<br /> and its reason sits in the per-CPU apf_reason.flags until<br /> __kvm_handle_async_pf() reads and clears it. If an NMI arrives after<br /> the event is injected and before the #PF handler reads the flags, and<br /> the NMI handler itself takes a #PF, that fault reads and clears the<br /> flags belonging to the #PF it interrupted. It then finds interrupts<br /> disabled in the NMI context it interrupted, and panics:<br /> <br /> Kernel panic - not syncing: Host injected async #PF in interrupt<br /> disabled region<br /> Call Trace:<br /> <br /> panic+0x52/0x60<br /> __kvm_handle_async_pf+0xb0/0xb0<br /> exc_page_fault+0x71/0xb0<br /> asm_exc_page_fault+0x27/0x30<br /> RIP: 0010:__get_user_nocheck_8+0x6/0x20<br /> perf_callchain_user+0x147/0x1a0<br /> get_perf_callchain+0x12d/0x1c0<br /> ...<br /> perf_event_nmi_handler+0x26/0x50<br /> exc_nmi+0xe8/0x110<br /> RIP: 0010:asm_exc_page_fault+0x0/0x30<br /> <br /> <br /> The last RIP line shows the NMI landing on the first instruction of<br /> the #PF entry. perf with user call chains takes such a fault: the<br /> sampling NMI walks the user stack with __get_user(), which faults when<br /> a saved frame pointer is not a valid user address or the walk runs off<br /> the top of the stack. The same window exists when KVM, running as an<br /> L1 hypervisor with DELIVERY_AS_PF_VMEXIT, reads the flags itself after<br /> a #PF VM-exit.<br /> <br /> The NMI entry code saves and restores CR2 for this nesting, but not the<br /> async #PF reason. Andy Lutomirski described the race, with perf as the<br /> example, when async #PF delivery was reworked in 2020 [1]. Saving and<br /> clearing the flags across the NMI, next to CR2, was discussed there but<br /> not merged.<br /> <br /> Since that rework, Linux has stopped setting KVM_ASYNC_PF_SEND_ALWAYS,<br /> so the host delivers "page not present" only for user mode faults and<br /> a kernel-mode fault in NMI context (including kernel-mode #MC and #DB)<br /> cannot be an async page fault. In that case, return without touching<br /> the flags so that the interrupted handler finds them intact.<br /> <br /> Tested on v7.3-rc5 in a 4-vCPU, 2 GiB guest restored from a snapshot<br /> whose memory is served on demand through userfaultfd, so that reading<br /> it back takes async #PFs, while every thread samples hardware cycles<br /> with user call chains and points its frame pointer at an unmapped page.<br /> Without this patch the guest panicked as above in 3 of 3 runs. With it,<br /> the guest survived 3 of 3 runs of 60 seconds, and the host counted<br /> 148,441 to 153,334 kvm_async_pf_not_present events in the first 20<br /> seconds of each. On 6.18.50 the results were the same: the guest<br /> panicked without the patch and survived with it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watch_queue: Fix note pool publication race in watch_queue_set_size()<br /> <br /> There is a race between watch_queue_set_size() and post_one_notification().<br /> watch_queue_set_size() publishes wqueue-&gt;notes, notes_bitmap, nr_pages and<br /> nr_notes with plain stores, and post_one_notification() reads them with<br /> plain loads under a different lock, so nothing orders the four stores<br /> against the poster&amp;#39;s loads: depending on the build, notes can be stored<br /> last (gcc 14 on x86-64 does this). Since keyctl_watch_key() lets a watch<br /> attach to a queue before it is sized, post_one_notification() can already<br /> be running on another CPU at that moment: it reads nr_notes &gt; 0, passes<br /> its bounds check, and then reads notes while it is still NULL,<br /> dereferencing notes[0].<br /> <br /> An unprivileged user triggers this reliably by watching one of its own<br /> keys through a notification pipe and racing ioctl(IOC_WATCH_QUEUE_SET_SIZE)<br /> on that pipe against keyctl(KEYCTL_SETPERM) on the key from another CPU,<br /> triggering:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> RIP: 0010:post_one_notification.isra.0+0xa2/0x1e0<br /> Call Trace:<br /> __post_watch_notification+0x148/0x180<br /> keyctl_setperm_key+0x119/0x130<br /> do_syscall_64+0x108/0x4c0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> Kernel panic - not syncing: Fatal exception in interrupt<br /> <br /> Fix this by publishing nr_notes last with smp_store_release(), and by<br /> reading it once with smp_load_acquire() in post_one_notification() before<br /> the bitmap and the page array are touched. A poster that observes a<br /> non-zero nr_notes then also observes the pool behind it; one that observes<br /> zero drops the notification as before.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> unicode: free the map after a grace period<br /> <br /> generic_ci_d_hash() and generic_ci_d_compare() read sb-&gt;s_encoding and<br /> dereference the unicode map while a pathwalk in rcu mode holds nothing<br /> but rcu_read_lock(). The filesystems that use them, ext4, f2fs and<br /> tmpfs, drop the map with utf8_unload() from -&gt;put_super(), which runs<br /> when the last reference to the mount goes away. A lookup that is still<br /> inside such a filesystem at that point reads a freed map.<br /> <br /> With a pathwalk held up in utf8_casefold_hash() while the last reference<br /> to a casefolded tmpfs goes away:<br /> <br /> BUG: KASAN: slab-use-after-free in utf8nlookup+0x74c/0x950<br /> Read of size 8 at addr ff110001030fe658 by task walker/98<br /> Call Trace:<br /> <br /> utf8nlookup+0x74c/0x950<br /> utf8byte+0x160/0x1560<br /> utf8_casefold_hash+0x167/0x230<br /> generic_ci_d_hash+0xdd/0x1c0<br /> link_path_walk+0x11ad/0x1d30<br /> path_lookupat+0x63/0xb00<br /> filename_lookup+0x1f1/0x5b0<br /> vfs_statx+0xd7/0x3b0<br /> [...]<br /> Allocated by task 94:<br /> __kmalloc_cache_noprof+0x249/0x560<br /> utf8_load+0x4e/0x570<br /> shmem_parse_opt_casefold.isra.0+0x92/0x270<br /> [...]<br /> Freed by task 97:<br /> kfree+0x1db/0x5b0<br /> shmem_put_super+0x72/0x170<br /> generic_shutdown_super+0x14c/0x530<br /> kill_anon_super+0x3a/0x60<br /> deactivate_locked_super+0x9c/0xf0<br /> cleanup_mnt+0x9f/0x130<br /> <br /> So far that has been hard to hit. umount(2) waits for a grace period<br /> in namespace_unlock() before it drops the mount, so only a mount whose<br /> last reference goes away elsewhere, like the close of a file or a chdir<br /> out of a lazily unmounted directory, can race a walker. So it is<br /> reachable.<br /> <br /> Delay the free until a grace period has passed. The map and the data<br /> table it holds a reference to then outlive any pathwalk that found the<br /> superblock before the mount went away. The reference on the data table<br /> module is dropped from the rcu callback as well. utf8-core is built in<br /> whenever CONFIG_UNICODE is set, so there is no module exit that would<br /> have to wait for the callbacks.<br /> <br /> Overlayfs points the s_encoding of an overlay at the map of its first<br /> layer without taking a reference of its own. That stays correct. The<br /> layer is held by the overlay, so its map is dropped only after the<br /> overlay is gone.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> autofs: ignore notification errors from a replaced pipe<br /> <br /> autofs_notify_daemon() takes a reference to the current notification<br /> pipe under wq_mutex, then drops the mutex before writing the request. The<br /> write can block while the daemon enters catatonic mode and installs a<br /> replacement pipe.<br /> <br /> If the old pipe&amp;#39;s reader is then closed, the delayed write returns -EPIPE<br /> and the generic error path enters catatonic mode again. That transition<br /> acts on the current superblock state, closes the replacement pipe, and<br /> releases the new daemon generation&amp;#39;s wait queues.<br /> <br /> Only enter catatonic mode when the pipe which failed is still the current<br /> pipe. Factor the already-locked transition so the identity check and state<br /> change are atomic with respect to another replacement.<br /> <br /> This was reproduced on v7.3-rc5-337-gff47652a4b66c in a local QEMU guest.<br /> An unprivileged UID 65534 lookup filled the old packet pipe before a<br /> normal CATATONIC/SETPIPEFD restart. On the unmodified kernel, the new pipe<br /> received HUP and both a pending victim lookup and a later lookup failed<br /> with ENOENT in two out of two fresh-mount runs.<br /> <br /> With this change, the new pipe remained active, received an intact<br /> 304-byte request, and both victim lookups completed in two out of two<br /> runs. Normal lookup and restart-without-a-blocked-writer controls passed.<br /> No KASAN, oops, refcount, or lock diagnostic was observed. A source<br /> reproducer and complete local logs are available privately on request.<br /> <br /> The demonstrated impact is limited to denial of a shared autofs service<br /> during a legitimate daemon restart. No memory corruption, information leak,<br /> privilege escalation, or code execution primitive was observed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rds: fix uninitialized trans dereference in CM event handler<br /> <br /> rds_rdma_cm_event_handler_cmn() assigns trans only when the RDMA<br /> device is an InfiniBand CA (RDMA_NODE_IB_CA). On any other device<br /> type, e.g. an iWARP RNIC such as siw, trans stays uninitialized, but<br /> the event switch dereferences it: unconditionally in the<br /> RDMA_CM_EVENT_CONNECT_REQUEST case via trans-&gt;cm_handle_connect(),<br /> and (with a connection context) in the ROUTE_RESOLVED and<br /> ESTABLISHED cases.<br /> <br /> An RDS listener on an iWARP device therefore crashes the kernel as<br /> soon as a connect request arrives: with CONFIG_INIT_STACK_ALL_ZERO<br /> the wild load becomes a NULL dereference at offset 0xa0<br /> (&amp;trans-&gt;cm_handle_connect) in the iw_cm_wq workqueue.<br /> <br /> GCC masks the bug in default builds by folding the uninitialized<br /> load into &amp;rds_ib_transport; Clang-built kernels take the real<br /> uninitialized path and oops.<br /> <br /> The active side can land on a non-IB device too: the id that<br /> rds_ib_conn_path_connect() creates is not restricted to a node type,<br /> so rdma_resolve_addr() binds it to whichever device serves the local<br /> address, and an iWARP RNIC on the same netdev qualifies. The crash<br /> there is different: resolving a route on an iWARP id never fills in<br /> cm_id-&gt;route.path_rec, and the ROUTE_RESOLVED case writes<br /> path_rec[0].sl before it calls into the transport.<br /> <br /> The iWARP transport was dropped long ago and IB is the only<br /> transport left, so make that explicit: initialize trans to<br /> &amp;rds_ib_transport at declaration, drop the conditional assignment,<br /> reject a connect request that arrives on a non-IB device, and drop a<br /> connection whose address resolved to one instead of resolving a<br /> route on it. The rejection is limited to RDMA_CM_EVENT_CONNECT_REQUEST<br /> on purpose: a non-zero return from the handler makes rdma_cm destroy<br /> the id the event was delivered on, which is right for the request&amp;#39;s<br /> freshly created id but would free a connection id that RDS still owns<br /> for any other event. On the active side the id stays ic-&gt;i_cm_id and<br /> the connection&amp;#39;s shutdown destroys it, so that case returns 0.<br /> <br /> [achender: reject only on RDMA_CM_EVENT_CONNECT_REQUEST instead of<br /> bailing out for every event on a non-IB device, so that rdma_cm does<br /> not destroy connection ids RDS still tracks; drop a connection whose<br /> address resolved to a non-IB device before a route is resolved on it;<br /> changelog adjusted]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: fix use-after-free in __tcf_action_put()<br /> <br /> __tcf_action_put() decrements the reference count before decrementing the<br /> binding count. Another thread can free the action between these operations,<br /> causing the binding-count update to access freed memory. KASAN reports it<br /> as:<br /> <br /> BUG: KASAN: slab-use-after-free in __tcf_action_put+0x327/0x340<br /> Write of size 4 at addr ff11000000d46420 by task tc-put-pause/64<br /> <br /> Hold the action IDR mutex across both counter updates and IDR removal,<br /> keeping cleanup outside the lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mshv_vtl: Check per-CPU register page before mmap<br /> <br /> Register-page setup is optional for each CPU. If allocation or<br /> registration fails, mshv_vtl_configure_reg_page() warns and leaves that<br /> CPU&amp;#39;s reg_page NULL, but initial context setup continues successfully.<br /> Meanwhile, successful setup on another CPU sets the global<br /> mshv_has_reg_page flag.<br /> <br /> mshv_vtl_fault() checks this global flag before selecting the requested<br /> CPU&amp;#39;s register page. With mixed setup results across online CPUs, the<br /> check passes even for a CPU with no register page, reaching<br /> get_page(NULL) when userspace faults in that mapping.<br /> <br /> Check the selected per-CPU register page before taking its reference and<br /> return VM_FAULT_SIGBUS if it is absent.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> futex: Fix mm reuse handling for FUT_OFF_MMSHARED<br /> <br /> A FUT_OFF_MMSHARED futex is a shared futex that refers to an MM.<br /> It is possible for a process to wait on a shared futex with a different MM<br /> because a FUT_OFF_INODE waiter can be requeued onto a FUT_OFF_MMSHARED<br /> futex by another process.<br /> This can cause FUT_OFF_MMSHARED waiters on a freed MM to consume<br /> wakeups intended for a newly allocated MM at the same address.<br /> <br /> Fix it by keying FUT_OFF_MMSHARED using a unique 64-bit per-MM ID.<br /> Leave private futexes as before to avoid influencing the performance of the<br /> hotpath.<br /> <br /> (Multi-threaded processes typically implicitly use FUT_OFF_MMSHARED by<br /> setting clear_child_tid such that it points into anonymous memory, which<br /> causes mm_release() in a multi-threaded mm to perform FUTEX_WAKE.)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> namespace: a mount that copy_tree() leaves out can&amp;#39;t take over a lock<br /> <br /> Since commit c62a4766937e ("move_mount: transfer MNT_LOCKED") a mount<br /> can be moved beneath a locked mount. The lock moves from the old cover<br /> to the new mount which takes over the job of hiding what&amp;#39;s under it and<br /> the old cover can be unmounted. That works as long as the new mount<br /> stays. But the caller picks the new mount and copy_tree() leaves a<br /> mount of a mount namespace file out of every copy made without<br /> CL_COPY_MNT_NS_FILE, together with everything mounted on it, and never<br /> looks at MNT_LOCKED. unshare(CLONE_NEWNS) and mount propagation make<br /> such copies.<br /> <br /> So a task that is root in its own user namespace gets rid of a locked<br /> cover on a file without a race and without touching the filesystem<br /> below it. It makes a child with a mount namespace of its own, binds the<br /> child&amp;#39;s /proc//ns/mnt beneath the cover with MOVE_MOUNT_BENEATH,<br /> which hands the lock to that bind, and calls unshare(CLONE_NEWNS). The<br /> new mount namespace has nothing on the file. That&amp;#39;s the usual way to<br /> mask a single file, a bind of /dev/null or of an empty file. With a<br /> bind of an ordinary file the file stays covered.<br /> <br /> copy_tree() already refuses to leave out a locked unbindable mount with<br /> -EPERM since commit df7342b24018 ("mount: Don&amp;#39;t allow copying<br /> MNT_UNBINDABLE|MNT_LOCKED mounts"). Do the same for a locked mount of a<br /> mount namespace file. That also covers a tree copied with<br /> CL_COPY_MNT_NS_FILE and attached into a mount namespace of another user<br /> namespace where lock_mnt_tree() locks it. Note that unshare(CLONE_NEWNS)<br /> and clone(CLONE_NEWNS) fail with EPERM from such a mount namespace from<br /> then on. The mount can&amp;#39;t be left out and it can&amp;#39;t be unmounted.<br /> <br /> And refuse to move a mount of a mount namespace file beneath a locked<br /> mount in the first place. Otherwise the task ends up with a mount it<br /> can&amp;#39;t unmount and an unshare() that fails for good.<br /> <br /> Chris also found a second mount that goes away by itself, a clone of an<br /> automounted mount that shrink_submounts() took along with its parent.<br /> Commit f78ddcc87224 ("namespace: never expire a locked mount") took<br /> care of that one.<br /> <br /> Chris&amp;#39;s reproducer is appended. Mode nsfile reads SECRET after the<br /> unshare() on 7.3-rc7, with this patch the move_mount() fails with<br /> EINVAL and the file stays covered. nsfile-control uses an ordinary file<br /> and reads MASK both ways.<br /> <br /> // SPDX-License-Identifier: GPL-2.0<br /> /*<br /> * Get rid of a locked cover with MOVE_MOUNT_BENEATH.<br /> *<br /> * The "admin" (root) makes a tmpfs W:<br /> * W/D file, holds SECRET, covered by a bind of a file with MASK<br /> * W/Dd/inner file, holds SECRET, Dd is covered by a bind of a directory<br /> * whose "inner" holds MASK<br /> * W/own directory of uid 1000 with the file "mine" and the<br /> * directory "minedir", whose "inner" holds MINE<br /> * W/dbg debugfs, mode 755. dbg/tracing is an automount point<br /> * The "attacker" is uid 1000. It enters a new user namespace with a new mount<br /> * namespace, so W and both covers are locked there.<br /> *<br /> * usage: prog MODE<br /> * plain put a bind of own/mine beneath the cover of D, unmount the cover<br /> * nsfile put a bind of the mount namespace file of a child beneath the<br /> * cover of D, then unshare(CLONE_NEWNS)<br /> * nsfile-control the same with a bind of own/mine<br /> * shrink put a bind of the automounted tracefs beneath the cover of Dd,<br /> * unmount the cover, put a tmpfs beneath W, call umount(W), which fails<br /> * shrink-control the same with a bind of own/minedir<br /> * The environment variable AUTOMOUNT_DIR names another automount point for "shrink".<br /> */<br /> #define _GNU_SOURCE<br /> #include <br /> #include <br /> #include <br /> #include <br /> #include <br /> #include <br /> #include <br /> #include <br /> #include <br /> <br /> ---truncated---