Vulnerability database

28,057 results · page 6 of 562

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: statmount: read the parent of an unmounted mount under mount_lock statmount_mnt_basic() reCVE-2026-98994 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: statmount: read the parent of an unmounted mount under mount_lock statmount_mnt_basic() reads the ids of the parent through m->mnt_parent with namespace_sem held for reading. That's fine for a mount that is in a namespace. Everything above it is pinned by that namespace. STATMOUNT_BY_FD also accepts a file descriptor on a mount that has been unmounted on purpose and that only the file descriptor keeps alive. If that mount stayed attached to its parent when it was unmounted the parent is unmounted as well and nothing pins it for the child. The final mntput() unmounts the children under mount_lock alone and frees the parent afterwards. Concurrently, statmount_mnt_basic() reads m->mnt_parent twice while that can happen and can easily dereference a mount that's already gone. Read the parent of an unmounted mount under mount_lock. The parent can't be put while it is held and both ids come from the same mount. A mounted mount's parent is pinned by the namespace and a mount can't leave its namespace while namespace_sem is held, so the common case takes no global lock.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: namespace: don't inherit MNT_UMOUNT in clone_mnt() MNT_UMOUNT gets raised on a mount that CVE-2026-98993 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: namespace: don't inherit MNT_UMOUNT in clone_mnt() MNT_UMOUNT gets raised on a mount that umount_tree() or umount_one() has taken out of its namespace. It's never cleared. __detach_mounts() unhooks a mount that carries it instead of unmounting it. disconnect_mount() lets an unmounted child stay attached only if its parent carries it. propagate_umount() takes it as the sign that a mount is going to be unmounted when it decides what else can be unmounted, where a chain of locked mounts ends and where a for reparenting an overmount. clone_mnt() copies the flags of the source and only masks MNT_INTERNAL_FLAGS which doesn't include MNT_UMOUNT. A mount that was lazily unmounted but is kept alive by a file descriptor can still be copied when its root is an nsfs or pidfs file because may_copy_tree() accepts those before checking whether the source is mounted at all: mount --bind /proc/self/ns/net /tmp/x exec 3< /tmp/x umount -l /tmp/x mount --bind /proc/self/fd/3 /tmp/y The mount on /tmp/y is attached to the caller's namespace with MNT_UMOUNT already set and every copy of it inherits the flag again. That cau

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: namespace: don't copy an unmounted mount tree may_copy_tree() accepts a mount whose root iCVE-2026-98992 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: namespace: don't copy an unmounted mount tree may_copy_tree() accepts a mount whose root is an nsfs or pidfs file before it checks whether that mount is mounted. This exception exists for nsfs and pidfs mounts. They are part of no mount namespace so neither check_mnt() nor is_mounted() would let them through and bind-mounting a nsfsfd or a pidfd wouldn't work. Problem is that exception also admits a bind mount of such a file when it was lazily unmounted and is only kept alive by a file descriptor: mount --bind /proc/self/ns/net /tmp/x exec 3< /tmp/x umount -l /tmp/x mount --rbind /proc/self/fd/3 /tmp/y With MS_REC or AT_RECURSIVE copy_tree() doesn't stop at the unmounted mount. It copies every mount that stayed attached to it as well. So if you have a bunch of overmounts over the nsfsfd or the pidfd the whole unmounted stack is copied. That's a bug. So refuse to walk an unmounted tree. Copying its root alone stays possible. So a bind mount of a namespace that is gone can still be recreated from a file descriptor on the old one. The file descriptor pins that mount and its root and __has_locked_children

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: namespace: queue a mount only once for mount notifications mnt_notify_add() puts a mount oCVE-2026-98991 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: namespace: queue a mount only once for mount notifications mnt_notify_add() puts a mount on notify_list. It doesn't check whether the mount is on the list already. That's fine as long as every mount is queued at most once per namespace_sem hold. It isn't. propagate_umount() moves a surviving overmount off a stack of mounts that are going away and queues it as moved. shrink_submounts() and mark_mounts_for_expiry() call umount_tree() for several mounts under a single namespace_sem hold. So the second umount_tree() can take down exactly the mount the first one reparented, reparent it once more and so end up queueing it a second time. The second list_add_tail() cuts the mounts queued in between out of the list while the head still points at the last of them. notify_mnt_list() then only visits that one mount and the others are freed after the grace period with notify_list still pointing at them. Every later mount operation on the host walks freed memory: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report Read of size 8 at addr ffff8881003d57e0 by task notify_dq/162 __list_add_valid_or_report+0x15c

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: namespace: check a submount for references right before unmounting it shrink_submounts() aCVE-2026-98990 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: namespace: check a submount for references right before unmounting it shrink_submounts() and mark_mounts_for_expiry() first collect all the mounts they are allowed to unmount and then unmount them. Whether a mount is busy is decided by propagate_mount_busy() on the tree. But unmounting the first mount changes the tree that the second one propagates into. propagate_umount() moves a surviving overmount off a copy it unmounts and mounts it where the copy was mounted. If that's where the propagated copy of the second victim is looked up the overmount becomes a candidate of the second umount_tree(). It's childless and so trim_one() commits it without looking at its reference count. So a synchronous umount pulls out a busy mount that is in use somewhere else and marks it MNT_SYNC_UMOUNT while it has users: umount2(/tmp/plshrink/p1, 0) = 0 errno 0 cwd is (unreachable) The same two umounts requested one after the other fail with EBUSY. This needs a mount with MNT_SHRINKABLE, i.e., automounted submounts of NFS, AFS and CIFS or the tracefs mount below debugfs. Bind mounts inherit the flag. Check each mount right b

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: namespace: check a recursive bind mount for mount namespace loops do_loopback() refuses toCVE-2026-98989 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: namespace: check a recursive bind mount for mount namespace loops do_loopback() refuses to bind mount the file of a mount namespace that is as old as the caller's or older because a mount namespace that holds a mount of its own file, or of an ancestor's, would cause a cycle. But it only checks the dentry the bind mount starts from. With MS_REC everything below it is copied and do_loopback() passes CL_COPY_MNT_NS_FILE so mount namespace files below the source are copied. That's fine for a source in the caller's own mount namespace. Every mount namespace file in there passed the same check when it was bind-mounted. It isn't fine for a source in another mount namespace. may_copy_tree() accepts a bind mount of any nsfs or pidfs file no matter what mount namespace it lives in so that /proc/<pid>/ns/<ns> and pidfds can be bind mounted. If we create a bind-mount stack of mount namespaces file descriptors the kernel will copy them irrespective of their ancestoral relationship to the mount namespace in question: 151 146 0:7 net:[4026531833] /tmp/nrc/y rw - nsfs nsfs rw 152 151 0:7 mnt:[4026532293] /tmp/nrc/y rw - ns

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: namespace: keep covered mounts covered in OPEN_TREE_NAMESPACE open_tree(OPEN_TREE_NAMESPACCVE-2026-98988 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8

  In the Linux kernel, the following vulnerability has been resolved: namespace: keep covered mounts covered in OPEN_TREE_NAMESPACE open_tree(OPEN_TREE_NAMESPACE) creates a new mount namespace from a copy of the tree at the given path. The caller needs to be privileged over its current user namespace because the new mount namespace will be owned by it. It doesn't need to be privileged over the mount namespace the tree is copied from. An unprivileged user just needs to create a user namespace first. The copy follows the rules of a detached bind mount. Without AT_RECURSIVE only the mount itself is cloned and its children are left out. With AT_RECURSIVE unbindable mounts are skipped. Both is fine when the caller has privileges over the source mount namespace because it could unmount those mounts anyway. Not so for an unprivileged user in that mount namespace. For them a mount namespace copy is what unshare() does. copy_mnt_ns() copies everything including unbindable mounts and lock_mnt_tree() makes sure nothing can be unmounted in the copy. Nothing that was covered gets revealed. create_new_namespace() only does the locking and so the covered content is right there in the new mount

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: namespace: look at the topmost mount for a mount namespace file attach_recursive_mnt() preCVE-2026-98987 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: namespace: look at the topmost mount for a mount namespace file attach_recursive_mnt() preallocates a mountpoint for the root of the topmost mount of the source so that a mount that already sits at the destination can be put on top of the source or on top of one of its propagated copies. The copies are made without CL_COPY_MNT_NS_FILE so their chain of overmounts is shorter than the source's. It ends below the first bind mount of a mount namespace file. So while the loop walks up the chain of the source it remembers the mountpoint of that mount in "shorter" and the existing mount is put there for the copies. But the loop ends at the topmost mount without ever looking at it. If the topmost mount is the only mount namespace file in the chain "shorter" stays NULL and mnt_change_mountpoint() attaches the existing mount of the copy below the root of the mount namespace file. That's a dentry of nsfs. No path walk in the copy's mount namespace ever gets there. The mount is gone until its parent goes and the copy that took its place can't be unmounted synchronously because it has a child: S bind mount of a file

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: namespace: remove the fsnotify marks of a mount namespace in process context mnt_ns_releasCVE-2026-98986 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: namespace: remove the fsnotify marks of a mount namespace in process context mnt_ns_release() drops the last passive reference of a mount namespace and removes its fanotify marks via fsnotify_mntns_delete(). That takes the mutex of every group with a mark on the namespace and the spinlock of the connector. Fine from process context. But mnt_ns_tree_remove() hands the reference the namespace was allocated with to call_rcu() and so the marks are removed from the RCU softirq: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:623 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/3 __mutex_lock+0x113/0x24b0 fsnotify_destroy_marks+0x11b/0x3d0 mnt_ns_release_rcu+0x57/0xa0 rcu_core+0x6b6/0x1e40 and lockdep complains about the connector lock being taken from softirq context. A fanotify group with a FAN_MARK_MNTNS mark on the mount namespace of another task is all that's needed. Root in a user namespace can do that for a mount namespace it owns. The task exits and the namespace is freed with the mark still on it. Remove the marks in free_mnt_ns() before th

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: namespace: check the mounts before reading their parents in pivot_root() path_pivot_root()CVE-2026-98985 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: namespace: check the mounts before reading their parents in pivot_root() path_pivot_root() reads the parents of new_root and of the caller's root and checks whether they are shared before it checks that either mount is in the caller's mount namespace. Only namespace_sem is held. That's fine for a mount that is in the caller's mount namespace. But new_root can be a file descriptor to a mount that has been unmounted and that only the file descriptor keeps alive. If that mount stayed attached to its parent when it was unmounted nothing pins the parent for it. The final mntput() of the parent unhooks the children under mount_lock alone and frees the parent afterwards: pivot_root() close(fd), last ref on the parent ------------ --------------------------------- ex_parent = new_mnt->mnt_parent mntput_no_expire_slowpath() __umount_mnt(new_mnt) cleanup_mnt() call_rcu() IS_MNT_SHARED(ex_parent) BUG: KASAN: slab-use-after-free in

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: dcache: don't put a mountpoint on a dentry that's being removed rmdir(), unlink() and renaCVE-2026-98984 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: dcache: don't put a mountpoint on a dentry that's being removed rmdir(), unlink() and rename() call dont_mount() on the victim and then detach_mounts() with the victim's inode locked. do_lock_mount() takes the inode lock of the mountpoint and checks cant_mount() so a mount can't show up after detach_mounts(). But attach_recursive_mnt() makes a second mountpoint for the root of the source mount so that the mounts already located at the destination can be put on top of it. No inode is locked for that one and d_set_mounted() only refuses a dentry that is unlinked. Between detach_mounts() and d_delete() the victim is still hashed: rmrace: b passed dont_mount() and detach_mounts(), sleeping T2: move_mount(S, /tmp/plcant/x, BENEATH) = 0 errno 0 () T1: rmdir(/tmp/plcant/d/b) = 0 errno 0 109 107 0:61 /d/b//deleted /tmp/plcant/x rw,relatime - tmpfs tmpfs rw 108 109 0:63 / /tmp/plcant/x rw,relatime - tmpfs T rw A bind mount of the directory that's being removed is moved beneath an existing mount while the rmdir() is located between the two calls. The mount ends up on the removed directory and nothing w

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: unshare: don't drop active namespace references that were never taken Active references onCVE-2026-98983 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: unshare: don't drop active namespace references that were never taken Active references on the namespaces of an nsproxy are taken when the nsproxy is installed into a task in switch_task_namespaces() and copy_namespaces() and dropped again by put_nsproxy() through deactivate_nsproxy(). But ksys_unshare() calls put_nsproxy() on an nsproxy that was never installed when set_cred_ucounts() fails. The new namespaces of that nsproxy go from zero to minus one and the namespaces shared with the caller lose a reference that belongs to the nsproxy the caller keeps using: WARNING: kernel/nscommon.c:171 at __ns_ref_active_put+0x1cd/0x230 nsproxy_ns_active_put deactivate_nsproxy ksys_unshare Afterwards the namespaces the caller lives in aren't listed by listns() anymore. set_cred_ucounts() only fails when alloc_ucounts() can't allocate and it only allocates when the real uid of the caller differs from its effective uid. Commit cefd55bd2159 ("nsproxy: fix free_nsproxy() and simplify create_new_namespaces()") separated the two cases on purpose. nsproxy_free() frees an nsproxy that was prepared but never installed

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: namespace: don't let a pseudo dentry become the root of a mount d_alloc_pseudo() hands outCVE-2026-98982 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: namespace: don't let a pseudo dentry become the root of a mount d_alloc_pseudo() hands out dentries for pipes, sockets and other files that are never anyone's child or parent. They carry DCACHE_NORCU and dentry_free() frees them right away because no lockless path walk can ever reach them. That holds as long as such a dentry isn't the root of a mount. But bind mounting /proc/self/fd/<fd> of such a file does exactly that. Most callers of alloc_file_pseudo() put their files on kernel-internal mounts and may_copy_tree() refuses those. bpf_token_create() doesn't. It places the token file on the bpffs mount the caller handed it and that mount is in the caller's mount namespace so the clone goes through: mount --bind /proc/self/fd/<token> <file> open_tree(tokfd, "", AT_EMPTY_PATH | OPEN_TREE_CLONE) + move_mount() __follow_mount_rcu() then loads ->mnt_root of that mount, reads d_seq and d_flags of the dentry and only then checks mount_lock. The dentry can be gone by then. The final mntput() of an unmounted parent unhooks a child that stayed attached to it under mount_lock alone. When the child's holder does the f

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: namespace: unhash a dentry before detaching the mounts on it unlink(), rmdir() and rename(CVE-2026-98981 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8

  In the Linux kernel, the following vulnerability has been resolved: namespace: unhash a dentry before detaching the mounts on it unlink(), rmdir() and rename() remove the entry from the filesystem, call detach_mounts() on the entry with the inode locked and then call d_delete() once the inode is unlocked. The thing is that between detach_mounts() and d_delete() the dentry is still hashed and positive. But after detach_mounts() nothing covers the dentry anymore. A lookup that finds this dentry in the dcache can uncover what the mounts hid. That's a problem when unlinking files or directories that are mountpoints in other mount namespaces. Everybody who had the underlying entry covered can race the detach_mount() call until d_delete() has run. The race window isn't all that small. It encompasses namespace_unlock() with a full synchronize_rcu_expedited() grace period and the inode_unlock() of the entry. In my experiments three walkers that kept trying read an overmounted file in 11938 of the 16140 unlinks that removed its mountpoint from a bind mount of the filesystem within a minute. Fun fact, d_invalidate() has the same ordering problem but gets it right. It unhashes the dent

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: namei: don't reveal overmounted entries in refwalk In rcuwalk the dentry is validated befoCVE-2026-98980 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8

  In the Linux kernel, the following vulnerability has been resolved: namei: don't reveal overmounted entries in refwalk In rcuwalk the dentry is validated before it is accepted. step_into() step_into() rechecks d_seq and __follow_mount_rcu() rechecks mount_lock. An entry that gets unlinked in between causes the lookup to retry and miss. A refwalk doesn't do this. lookup_fast() takes a reference on the hashed dentry and simply accepts it. So an unlink that happens after the reference was taken isn't seen by refwalk. That's fine for a simple file. We just happened to open it before it was unlinked, no problem. For a mountpoint and specifically a locked mountpoint it very much isn't. The unlink detaches all mounts and then removes the name. Any refwalk that hasn't traversed the mounts yet simply reveals the underlying entry. It's a very narrow window but it can be hit: reads of a covered file in 60 s, 3 walkers, ~15000 unlinks no widening 27 that step + 200 us 3741 See the appended patch for a more reliable reproducer. So check the entry after step_into(). unlink(), rmdir() and rename() mark the dentry with dont_mount() before they detach the mounts and re

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: namespace: refuse an automount below a mount that is in no namespace It's possible to add CVE-2026-98979 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: namespace: refuse an automount below a mount that is in no namespace It's possible to add autmounts even when the parent mount isn't in the mount namespace of the caller. The only requirement we have is that the parent mount namespace must not be NULL, i.e., unmounted. Problem is that clone_private_mount() has MNT_NS_INTERNAL which makes that trivially true. So that passes the test and attach_recursive_mnt() accepts that as a mount point and funny enough, count_mounts() dereferences MNT_NS_INTERNAL. The problem is it is an error pointer... So we can reach this in userspace via fanotify. A filesystem mark on the lower filesystem of an overlay reports paths on the layer clone and reading the event hands out a descriptor on it. For example with debugfs as the lower layer it goes kaboom: openat(evfd, "tracing", O_DIRECTORY) Oops: general protection fault KASAN: null-ptr-deref in range [0x1d0-0x1d7] RIP: 0010:count_mounts+0x35/0x200 attach_recursive_mnt finish_automount And since that sleeping beauty happens under namespace_sem held for writing every mount operation on the system blocks from then on

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: namespace: never expire a locked mount Locked mounts are special.CVE-2026-98978 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.4

  In the Linux kernel, the following vulnerability has been resolved: namespace: never expire a locked mount Locked mounts are special. They protect the underlying files and directories from being revealed. do_umount() refuses to unmount locked mounts but shrink_submounts() doesn't. A shrinkable mount can become locked once the owner of a user namespace puts it beneath a locked mount with MOVE_MOUNT_BENEATH. The locked property now moves to the mount at the bottom making it possible to unmount the top mount. So umount() of an unlocked ancestor now expires the bottom mount first and the covered directory is revealed: move_mount(c -> x/hidden, MOVE_MOUNT_BENEATH) = 0 the cover after the lock moved: umount2(x/hidden) = 0 the holder of the lock: umount2(x/hidden) = EINVAL the root of the copy, busy: umount2(x) = EBUSY reads x/hidden/secret: "covered-by-root" So leave a locked mount alone as it dies together with its parent. A plain umount() of an unlocked mount with a locked one below it is EBUSY from now on. It's the same for any other locked child. A lazy umount still takes the whole tree. mark_mounts_for_expiry() never sees a locked mount. lock_mnt_tree

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: namespace: handle mount locking for automounts correctly If mounts are propagated across uCVE-2026-98977 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: namespace: handle mount locking for automounts correctly If mounts are propagated across user namespaces, attach_recursive_mnt() locks every copy of the source mount to protect overmounts from vanishing and revealing the underlying files or directories. The user namespace is taken from the caller's mount namespaces since this is where the mounts end up. Except, that's not always true. Automounts may legitimately get popped in by tasks located in a different mount and user namespace during path lookup. Then check doesn't make sense at that point. The copy in the namespace of the parent - which may be the host's - is now locked and the host cannot change the flags of its own mounts anymore. Here's the reproducer: - host has debugfs mounted nosuid,nodev,noexec and shared - tracefs automount below it is not yet active - hand a child process a directory descriptor on that mount - child process enters auser and mount namespace - child process' namespace now holds a locked copy of the host's debugfs mount that receives propagation from it - child process stats "tracing/." through the descriptor - lookup runs on th

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: namespace: keep the lock on a mount that a propagated copy is moved beneath attach_recursiCVE-2026-98976 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: namespace: keep the lock on a mount that a propagated copy is moved beneath attach_recursive_mnt() transfers MNT_LOCKED from the top mount to the mount that is moved beneath it with MOVE_MOUNT_BENEATH. This allows the owner of a user namespace to replace its locked /proc or its root. The mount beneath takes on the job of covering the underlying mountpoint allowing the top mount to be unmounted. Consider two mount namespaces: (H) The host H has a shared mount P with a secret in P/d (Z) Z is a user namespace made from M. Its copy of P receives propagation from the host's P and its copy of M's cover on P/d is locked Z's owner must not get to see P/d. Now (H) mounts X on P/d. This propagates into (Z). The copy of X lands beneath (Z)'s locked cover. The locked property is transfered from (Z)'s cover to the copy of X propagated beneath it. The cover is now unlocked. Now (H) unmounts X again. The copy of X in (Z) gets unmounted and the covering mount is left unlocked on top of P/d. (Z) can now unmount it: Z: umount2(P/d) = EINVAL /* the cover is locked */ H: mount X on P/d, um

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: xfs: stop exchanging reflink flags when exchanging mappings When an exchange covers both fCVE-2026-98975 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: xfs: stop exchanging reflink flags when exchanging mappings When an exchange covers both files from offset 0 to i_disk_size, xmi_can_exchange_reflink_flags() assumes every mapping moved and hands the reflink flag over to the other file. That assumption is wrong. A file can still own shared blocks past i_disk_size, e.g. after EXCHANGE_RANGE_TO_EOF sets a smaller size without unmapping anything. The flag is cleared anyway, and the next write to such a block happens in place instead of CoW, corrupting the other file that shares it. Commit a23eca88448e ("xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN") fixed one instance of this. Rather than add another special case, stop moving the flags. xfs_exchmaps_ensure_reflink() already sets the flag on both inodes before the exchange, so both just keep it. Nothing sets CLEAR_INO{1,2}_REFLINK anymore. Intents logged by older kernels may still carry them; recovery already masks them off, so they stay in the log format mask and are ignored. XFS_IOC_SWAPEXT has the same problem: it moves the reflink flag from one inode to the other along with the ex

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: xfs: fix exchange-range-to-eof file size exchange Norbert Szetei posted a patch containingCVE-2026-98974 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: xfs: fix exchange-range-to-eof file size exchange Norbert Szetei posted a patch containing an incomplete description of a bug in XFS_IOC_EXCHANGE_RANGE's TO_EOF flag. The bug tricks exchange-range into modifying a file so that it has shared blocks starting beyond EOF, which is never allowed because files never have written data beyond EOF, and you can only share written data blocks. This is key to all the incorrect behavior that follows. Eventually I got from Norbert a description of what's going wrong: > Fair. Here it is with physical block numbers, 4k blocks. peer is the file > that gets rewritten and file1 is the one that ends up with the flag > cleared. > > Start, nothing shared: > > peer size 4096 -> [100] > file1 size 12288 -> [200] [201] [202] > donor1 size 4096 -> [300] > donor2 size 4096 -> [400] > > 1. FICLONERANGE peer's block into file1's middle slot: > > peer size 4096 -> [100] > file1 size 12288 -> [200] [100] [202] reflink flag set > ^^^^^ both files own block 100 > > 2. XFS_IOC_EXCHANGE_RANGE file1 against donor1, file1_offset 0, > file2_offset 8192, length 0, TO

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: drm/bridge: Fix unlocked list_del in drm_bridge_add() When re-adding a bridge that was preCVE-2026-98973 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: drm/bridge: Fix unlocked list_del in drm_bridge_add() When re-adding a bridge that was previously removed, drm_bridge_add() drops it from bridge_lingering_list without holding bridge_lock. Both bridge_list and bridge_lingering_list are protected by bridge_lock, as they are concurrently modified by drm_bridge_remove() and __drm_bridge_free(), and walked by the debugfs 'bridges' file. Running the list_empty() test and the list_del_init() outside of the lock may therefore corrupt either list. Perform both under bridge_lock.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Don't access cpuset_cgrp_subsys.root in is_in_v2_mode() After seeing the paCVE-2026-98972 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Don't access cpuset_cgrp_subsys.root in is_in_v2_mode() After seeing the patch [1] to guard is_in_v2_mode() with RCU, it makes me realize that is_in_v2_mode() may be called in a context where a new cgroup filesystem is being rebound with stale cpuset_cgrp_subsys.root pointer. Avoid this potential UaF situation by adding a new cpuset_v2_mode flag which is set when the cpuset_v2_mode mount option is used. This flag is written into only when cpuset_bind() is being called with a stable cpuset_cgrp_subsys.root value. The is_in_v2_mode() helper is modified to read the new cpuset_v2_mode flag instead of accessing cpuset_cgrp_subsys.root directly. [1] https://lore.kernel.org/lkml/20260929084124.626693-2-arighi@nvidia.com

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: gpio: exar: initialize the ID before registering its cleanup devm_add_action_or_reset() inCVE-2026-98971 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: gpio: exar: initialize the ID before registering its cleanup devm_add_action_or_reset() invokes the cleanup action immediately when registering the action fails. gpio_exar_probe() currently stores the allocated ID in exar_gpio only after registering the action, so that failure makes exar_devm_ida_free() release ID 0. If the allocated ID is nonzero, this leaks that ID and can free ID 0 belonging to another device. Store the ID before registering the cleanup action so both the immediate failure path and normal device teardown release the correct allocation.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Free the BO cache size list on teardown vc4_bo_cache_destroy() purges the cached CVE-2026-98970 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Free the BO cache size list on teardown vc4_bo_cache_destroy() purges the cached BOs but never frees the size list, leaking it on every unbind.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: net/sched: em_text: reject unterminated algo before autoload This is a follow-up to commitCVE-2026-98969 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: net/sched: em_text: reject unterminated algo before autoload This is a follow-up to commit 9c572a83037a ("net/sched: fix potential stack infoleak in em_text_dump()"), which zero-initialised the dump-side struct. Sashiko pointed at a pre-existing bug that exposed the change-side input-validation gap open. em_text_change() casts the raw netlink attribute payload to struct tcf_em_text and passes conf->algo, a 16-byte array with no enforced NUL terminator, to textsearch_prepare(). On the TS_AUTOLOAD retry textsearch_prepare() calls request_module("ts_%s", algo); vsnprintf() walks %s until it finds a NUL, so an algo[] with no NUL reads past the array into the adjacent struct fields and payload and feeds those bytes to the usermode helper command line. This is an out-of-bounds read and a kernel memory disclosure. Reject the attribute when no NUL exists within TC_EM_TEXT_ALGOSIZ bytes, matching the check xt_string has had since 3ab720881b6e. Conditions to recreate the bug: - CAP_NET_ADMIN on the target netns (namespace-local via unshare -Urn is enough) - install clsact on an interface, then add a basic filter wit

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: amt: send the relay's General Query directly from the receive path An skb queued in a qdisCVE-2026-98968 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.1

  In the Linux kernel, the following vulnerability has been resolved: amt: send the relay's General Query directly from the receive path An skb queued in a qdisc can outlive the tunnel it references through a raw pointer in skb->cb. For example, with igmp_qrv set to 1 on the relay a tunnel lives for 135s, so a netem delay of 180s on the amt device outlives it; when the tunnel expires and is freed, the subsequent dequeue triggers a use-after-free in amt_dev_xmit(). BUG: KASAN: slab-use-after-free in amt_dev_xmit+0x2763/0x2e20 Call Trace: amt_dev_xmit+0x2763/0x2e20 [drivers/net/amt.c:1262] dev_hard_start_xmit+0x22f/0x620 sch_direct_xmit+0x12e/0xac0 netem_dequeue+0x333/0xc50 net_tx_action+0x35c/0xa60 amt_send_igmp_gq() and amt_send_mld_gq() are only called from amt_request_handler(), inside the rcu_read_lock_bh() section of amt_rcv(). amt_request_handler() already has the tunnel the query is for: it found or created it inside that section. Queuing the query with dev_queue_xmit() only leads back into amt_dev_xmit(), which strips the Ethernet header and calls amt_send_membership_query() for that tunnel. Make that call directly from the two senders instead, the same

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: cxgb4/ch_ktls: disable softirqs around tid_list erases chcr_ktls_cpl_act_open_rpl() insertCVE-2026-98967 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: cxgb4/ch_ktls: disable softirqs around tid_list erases chcr_ktls_cpl_act_open_rpl() inserts into tid_list from the receive path using xa_insert_bh(). The array is shared by the adapter's connections and initialized with XA_FLAGS_LOCK_BH. However, chcr_ktls_dev_del() and the chcr_ktls_dev_add() error path use xa_erase(), which takes the XArray lock without disabling softirqs. When cleanup runs with softirqs enabled, a receive softirq for another connection on the same CPU can interrupt the erase and spin on the lock held by the interrupted task. Use xa_erase_bh() at both sites to match the insertion path.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: bonding: fix the program leak when XDP is replaced We need to release the reference on theCVE-2026-98966 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: bonding: fix the program leak when XDP is replaced We need to release the reference on the old BPF prog, whether we are going to no-prog, or replacing the prog with another. Spotted by AI while running tests for the propagation series (leaked programs were accumulating). Selftest will come in the net-next series to avoid conflicts.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: ice: Restore Ordered MMIO Writes for Tx Doorbells The DQL accounting state which tracks thCVE-2026-98965 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5

  In the Linux kernel, the following vulnerability has been resolved: ice: Restore Ordered MMIO Writes for Tx Doorbells The DQL accounting state which tracks the number of bytes queued for the NIC to transmit, namely dql->num_queued, is updated by the ICE driver when it invokes __netdev_tx_sent_queue(). Subsequently the driver updates the hardware queue tail allowing the NIC to begin processing the work queue. The queue accounting update should be ordered before the NIC begins transmitting descriptors. The transmit path currently updates the hardware doorbell using writel_relaxed(), which (on arm64) does not provide the same ordering guarantees between writes to normal memory and writes to MMIO registers that writel() does. This introduces a potential race where the NIC begins transmitting descriptors before the dql->num_queued update is globally visible. If the NIC finishes before the update is observed by dql_completed(), it detects an invalid state where more bytes have been completed than have been queued. When this happens the following BUG_ON is triggered. BUG_ON(count > num_queued - dql->num_completed); This has been observed and manifests as the following crash (note t

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: nvmet: use the local P2P device on metadata allocation failure nvmet_req_alloc_p2pmem_sglsCVE-2026-98964 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5

  In the Linux kernel, the following vulnerability has been resolved: nvmet: use the local P2P device on metadata allocation failure nvmet_req_alloc_p2pmem_sgls() assigns req->p2p_dev only after the data and metadata SGL allocations succeed. If the data allocation succeeds but the metadata allocation fails, out_free_sg passes req->p2p_dev to pci_p2pmem_free_sgl() before that assignment has taken place. Pass the local p2p_dev argument instead, so cleanup uses the same PCI device as the successful data allocation.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: btrfs: always return -EIOCBQUEUED after btrfs_uring_read_extent_endio If all bios finish bCVE-2026-98963 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: btrfs: always return -EIOCBQUEUED after btrfs_uring_read_extent_endio If all bios finish before btrfs_encoded_read_regular_fill_pages() returns, it calls btrfs_uring_read_extent_endio() and previously returned the I/O status. A negative errno then made btrfs_uring_read_extent() unlock and free while btrfs_uring_read_finished() did the same again. Return -EIOCBQUEUED so only the deferred path cleans up.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: btrfs: free iov when btrfs_uring_read_extent() fails After btrfs_uring_read_extent(), the CVE-2026-98962 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: btrfs: free iov when btrfs_uring_read_extent() fails After btrfs_uring_read_extent(), the caller always jumped to out_acct. That skips kfree(data->iov), which is only correct for -EIOCBQUEUED where the deferred path owns the iov. On failure, fall through to out_free instead.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: btrfs: unlock inode and extent in caller when io_uring read extent fails btrfs_uring_read_CVE-2026-98961 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: btrfs: unlock inode and extent in caller when io_uring read extent fails btrfs_uring_read_extent() runs only after btrfs_encoded_read() has taken the inode shared lock and the extent lock. On failure it used to unlock in out_fail, and a pages-array allocation failure returned -ENOMEM without unlocking at all. Unlock in the caller instead on all failure returns, matching the copy_to_user() error path. The deferred -EIOCBQUEUED path still unlocks in btrfs_uring_read_finished().

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: btrfs: don't stash io_uring encoded data across -EAGAIN Returning -EAGAIN while leaving btCVE-2026-98960 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: btrfs: don't stash io_uring encoded data across -EAGAIN Returning -EAGAIN while leaving btrfs_uring_encoded_data in the cmd PDU leaks if the request is cancelled or the ring exits before reissue. io_uring does not free driver PDU allocations on cleanup. Write: io_queue_sqe() always issues with IO_URING_F_NONBLOCK first, so return -EAGAIN before allocating and free data on every exit. Read: free on nowait -EAGAIN too; only -EIOCBQUEUED keeps the allocation for btrfs_uring_read_finished().

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: btrfs: fix xattr replace when multiple xattrs are packed in the same item If we have a btrCVE-2026-98959 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

  In the Linux kernel, the following vulnerability has been resolved: btrfs: fix xattr replace when multiple xattrs are packed in the same item If we have a btrfs_dir_item item that packs multiple xattrs and then we replace the value of one of them (with the setxattr(2) family of syscalls) with another value of a different size, we end up not having a fully initialized btrfs_dir_item, resulting in a corruption that the tree checker will detect at extent buffer writeback time. This is because in btrfs_setxattr() when we find a btrfs_dir_item with multiple xattrs (due to the crc32c hash of their name being the same) we delete one of the xattr items (btrfs_dir_item) and then insert a new one, but the deletion and insertion results in shifting existing data in the leaf and therefore when the new value of a xattr has a different size, the new btrfs_dir_item is placed in a leaf section that was not initialized and we only copy the value's data and set the value's length in the new btrfs_dir_item, without setting the name, the name's length, the key (which must be all zeroes for xattrs), flags (BTRFS_FT_XATTR) and transaction ID. The following script reproduces the issue: $ cat test.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: account non-AQL frames per peer rather than per link The driver increments wciCVE-2026-98958 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: account non-AQL frames per peer rather than per link The driver increments wcid->non_aql_packets when a frame goes to the hardware queue. The completion path decrements the counter again. For an MLO peer, the hardware reports the completion on the link that it used for the transmission. This link can differ from the link that the driver queued the frame on. In that case, the increment and the decrement go to different link wcids, and the count drifts upwards until it blocks the station. Keep the count on the wcid of the primary link, like the other peer-wide state.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: disable rx napi when removing device Unloading the mt7915e module withCVE-2026-98957 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: disable rx napi when removing device Unloading the mt7915e module with a MT7916 triggers multiples WARN in __netif_napi_del_locked() and in page_pool_disable_direct_recycling() because the driver does not disable the napi before destroying it. This is troublesome since on MT7916 it is required to unload the module and reinsert it with a different enable_6ghz parameter to change the frequency. The system generally becomes unstable after reinserting the module. Fix it by disabling rx napi inside mt7915e itself, even through napi rx is enabled in the mt76 generic code. Disabling it in the mt76 generic code was previously attempted and reverted because napi was disabled too late and rx handlers could access freed structures. Note that the tx side is enabled and disabled by the mt76 generic code. It is disabled in mt7915_stop_hardware() since, unlike mt7915_unregister_device(), is it also called in the probe path if an error happens after rx napi is enabled.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: ASoC: adau1372: allow sleepy powerdown GPIOs gpiod_set_value() emits a WARN when the GPIO CVE-2026-98956 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: ASoC: adau1372: allow sleepy powerdown GPIOs gpiod_set_value() emits a WARN when the GPIO provider indicates that it can sleep, as is typical for I2C controlled GPIO expanders. Since the powerdown GPIO is only manipulated in process context, use the _cansleep variant instead. This lets the driver use sleepy GPIOs to power off the chip.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: flow_dissector: avoid u16 truncation of skb->len when computing thoff __skb_flow_dissect()CVE-2026-98955 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: flow_dissector: avoid u16 truncation of skb->len when computing thoff __skb_flow_dissect() computes key_control->thoff using: key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen); min_t(u16, ...) casts both arguments to u16 before comparing them. Whenever skb->len (or hlen) modulo 65536 is smaller than nhoff, the truncated length wins and thoff is set to a bogus small value, even when the dissection succeeded. For example, an IPv4/TCP frame with skb->len == 65540 and nhoff == 34 gets thoff == 4, so callers such as skb_probe_transport_header() point the transport header inside the Ethernet header. Such skbs are not exotic: - At the time of commit d0c081b49137 ("flow_dissector: properly cap thoff field"), AF_PACKET with PACKET_VNET_HDR could already build GSO skbs larger than 64KB (MTU checks are skipped for GSO, and alloc_skb_with_frags() accepted up to MAX_SKB_FRAGS (17) order-0 pages on top of the linear part). - BIG TCP now makes skbs larger than 64KB common. - The following patch makes tun_get_user() dissect IFF_TAP frames before eth_type_trans() pulls the Ethernet header, so a GSO fram

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: net: always dissect GSO packets in __virtio_net_hdr_to_skb() Commit 9e8db5913264 ("net: avCVE-2026-98954 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: net: always dissect GSO packets in __virtio_net_hdr_to_skb() Commit 9e8db5913264 ("net: avoid false positives in untrusted gso validation") added a '&& skb->network_header' check before flow-dissecting GSO packets without VIRTIO_NET_HDR_F_NEEDS_CSUM in __virtio_net_hdr_to_skb(), because some callers (such as tun_get_user(), tun_xdp_one(), virtnet_receive_done(), and raw_verify_header()) called virtio_net_hdr_*_to_skb() before initializing skb->network_header and skb->dev. Because __alloc_skb() and __build_skb_around() zero-initialize skb->network_header to 0 (unlike mac_header and transport_header which are initialized to ~0U), those four callers always had skb->network_header == 0 and bypassed flow dissection in __virtio_net_hdr_to_skb(). More generally, skb->network_header is an offset from skb->head (where 0 is also a valid offset whenever skb_headroom(skb) is 0), not a boolean flag. Whenever the 'if (gso_type && skb->network_header)' branch was skipped, the fallback 'else if (gso_type)' only pulled nh_min_len + thlen (40 bytes for TCPv4) without dissecting the packet, without validating ip_proto or n_proto,

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: devlink: fix devlink_rel reference leak when notify work is pending devlink_rel_nested_in_CVE-2026-98953 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: devlink: fix devlink_rel reference leak when notify work is pending devlink_rel_nested_in_notify_work_schedule() takes a reference on the devlink_rel for the notify work and then queues the work, ignoring the return value of schedule_delayed_work(). If the work is already pending, nothing new is queued, the work runs only once and drops only one reference, so the extra one is leaked together with the devlink_rel and its index in devlink_rels. This is easy to hit. devl_register() of a nested instance queues the work, and if the instance is unregistered before the work has run, devlink_rel_put() queues it again while it is still pending. The work also keeps rescheduling itself for as long as the parent devlink lock cannot be taken, which widens the window. Registering and unregistering a nested devlink instance 100 times while holding the parent lock leaks all 100 devlink_rel objects. The reschedule path in devlink_rel_nested_in_notify_work() has the same problem: if the work was queued again while it was running, the reference it holds is never dropped. Drop the reference in both places when the work was alread

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: pfcp: make sure the SEID is linear before reading it pfcp_encap_recv() only makes sure thaCVE-2026-98952 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.3

  In the Linux kernel, the following vulnerability has been resolved: pfcp: make sure the SEID is linear before reading it pfcp_encap_recv() only makes sure that the UDP header and the 4 byte PFCP header are in the linear area. When the S flag is set, pfcp_session_recv() then reads the 8 byte SEID that follows, which is not covered by the pskb_may_pull() check. A short PFCP packet with the S flag set, or one whose session header lies in a fragment, therefore makes pfcp_session_recv() read beyond the end of the packet data, and whatever it finds there is stored in the tunnel metadata that flower later classifies on. Pull up to the end of the SEID before reading it, and drop packets that are too short to contain it. Reload the header pointer afterwards since pskb_may_pull() may reallocate the skb head. Use offsetofend() rather than sizeof(struct pfcphdr_session): the structure is not packed, so its size is 16 bytes because of the alignment of the __be64 member, while the header on the wire is only 12 bytes, and valid session messages would be dropped.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: riscv: ptrace: Zero-initialize regset buffers before copyin user_regset_copyin() only copiCVE-2026-98951 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: riscv: ptrace: Zero-initialize regset buffers before copyin user_regset_copyin() only copies `count` bytes, so a PTRACE_SETREGSET request with a short iov_len leaves the rest of the stack buffer uninitialized. In riscv_vr_set() that garbage is validated and copied into the target's vstate, and in riscv_cfi_set() it can be stored as the target's shadow stack pointer. Zero both buffers, as the get path already does.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect() bpf_flow_dissect() saniCVE-2026-98950 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect() bpf_flow_dissect() sanitizes the offsets returned by the BPF program with clamp_t(u16, ..., hlen). If hlen is bigger than 65535, the upper bound is truncated before the comparison. For instance, with hlen == 65536, both nhoff and thoff are forced to zero, even if the program returned sane values. This is the same class of bug as the one fixed in commit 99bda1ecbd56 ("flow_dissector: avoid u16 truncation of skb->len when computing thoff"). That fix does not cover the BPF path, because __skb_flow_dissect() returns early when a BPF flow dissector handles the packet. struct bpf_flow_keys stores nhoff and thoff as u16, so cap hlen to U16_MAX before clamping. Found by sashiko while reviewing the commit above.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix reference and vm_bo handling in remap() When a map overlaps part of aCVE-2026-98949 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix reference and vm_bo handling in remap() When a map overlaps part of an existing mapping, pvr_vm_gpuva_remap() splits the mapping into prev/next parts covering what the request did not take, instead of creating something new. It gets two things wrong. - A GEM reference is taken for each part but it's never needed and never dropped, so it leaks one reference per split (remap-next-in-2m in tests/imagination/pvr_vm_map.c): CRITICAL: 33558528 bytes of shmem still held after close - The parts still belong to the original object being split, but pvr_vm_gpuva_remap() links them to ctx->gpuvm_bo, the new object's vm_bo: prev_va --obj--> BO_A BO_B <--obj-- vm_bo (ctx->gpuvm_bo) \___________link___________/ (mismatch: BO_A != BO_B) drm_gpuva_link() catches the mismatch: WARNING: drivers/gpu/drm/drm_gpuvm.c:2108 at drm_gpuva_link+0x2ec/0x310 drm_WARN_ON(obj != vm_bo->obj) Call trace: drm_gpuva_link pvr_vm_gpuva_remap __drm_gpuvm_sm_map pvr_vm_map pvr_ioctl_vm_map Link them to op->remap.unmap->va->vm_bo instead. The l

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_flower: Fix port range register leak in tmplt_create() mlxsw_sp_flower_tmpCVE-2026-98948 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_flower: Fix port range register leak in tmplt_create() mlxsw_sp_flower_tmplt_create() parses a flow_cls_offload template into a stack-local struct mlxsw_sp_acl_rule_info purely to compute rulei.values.elusage. Parsing can acquire port range registers via mlxsw_sp_flower_parse_ports_range(), but since this rulei never goes through mlxsw_sp_acl_rulei_destroy(), those registers were never released, including through chain template deletion. Factor out of mlxsw_sp_acl_rulei_destroy() the code to actually release the necessary resources and call from mlxsw_sp_flower_tmplt_create() to plug the leak. The issue was found during a review of Wentao Liang's patch referenced below.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: vsock: Fix memory leak in vmci_transport_recv_dgram_cb() During the closure of a datagram CVE-2026-98947 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: vsock: Fix memory leak in vmci_transport_recv_dgram_cb() During the closure of a datagram socket, the vmci_transport_recv_dgram_cb() function may be called, which will add the packets to the socket's backlog; then, after the receive queue is cleared, the __release_sock() function will move the packet back from the socket's backlog to the receive queue, which will lead to a memory leak. sock_close __sock_release __vsock_release // take ownership by user-space lock_sock_nested sock_set_flag(sk, SOCK_DEAD) vmci_transport_release vmci_dispatch_dgs vmci_datagram_invoke_guest_handler vmci_transport_recv_dgram_cb sk_receive_skb if (!sock_owned_by_user(sk)) [...] (!) else if sk_add_backlog() [...] (!) skb_queue_purge(&sk->sk_receive_queue)

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Disable the V3D interrupt across runtime suspend vc4_irq_disable() masks the V3D CVE-2026-98946 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Disable the V3D interrupt across runtime suspend vc4_irq_disable() masks the V3D interrupt sources and then calls synchronize_irq() before the V3D is powered down. However, by itself, this is not enough to quiesce the interrupt handler. synchronize_irq() waits for handlers that have already set IRQD_IRQ_INPROGRESS, and for irqchips reporting IRQCHIP_STATE_ACTIVE. A GIC interrupt chip is able to mark an interrupt active as soon as a CPU acknowledges it, so there these checks cover the whole dispatch path. On RPi 0-3, however, the interrupt controller is ARMCTRL, which has no active state. A CPU that has read the hwirq out of the pending register but has not yet reached handle_level_irq() stays invisible to synchronize_irq(). During a power transition, vc4_irq() may therefore run after the power domain is off, where every V3D register read will return 0xdeadbeef. 0xdeadbeef has FLDONE, FRDONE and OUTOMEM set. This problem doesn't trigger NULL pointer dereference issues only because the functions vc4_irq_finish_bin_job() and vc4_irq_finish_render_job() return early when there is no job pointer, but OUTOME

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Oct 23, 2026In the Linux kernel, the following vulnerability has been resolved: HID: steam: Rearrange teardown sequence This fixes a narrow window during the teardown seqCVE-2026-98945 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: HID: steam: Rearrange teardown sequence This fixes a narrow window during the teardown sequence where callbacks could still be scheduled during cleanup that would then have a dangling pointer to the now-freed steam struct. This also puts work canceling for rumble and mode switch in steam_unregister, as that shouldn't persist while the client hdev is open.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.