p PatchFirst

PatchFirst · Latest vulnerabilities

Operating systems stack vulnerabilities · Page 16

Vulnerabilities published for Operating systems in the last 30 days: 6392. Listed in the KEV catalogue: 2.

RSS ↗ JSON ↗
Filter vulnerabilities
Operating systems

Vulnerabilities: 159106

  1. CVE-2026-98998

    Not ratedEPSS 0.16%Fix available

    drm/bridge: th1520-dw-hdmi: Fix remove() callback

    In the Linux kernel, the following vulnerability has been resolved: drm/bridge: th1520-dw-hdmi: Fix remove() callback This driver stores struct th1520_hdmi * in platform drvdata, but th1520_dw_hdmi_remove() was reading it back as struct dw_hdmi * and passing it to dw_hdmi_remove(), so teardown runs on the wrong pointer. Retrieve struct th1520_hdmi * from platform drvdata and pass hdmi->dw_hdmi to dw_hdmi_remove().

    linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hwe linux-azure linux-gcpOperating systems
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  2. CVE-2026-98997

    Not ratedEPSS 0.17%Fix available

    drm/amdgpu/userq: only accept doorbell BOs as queue doorbell

    In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: only accept doorbell BOs as queue doorbell amdgpu_userq_get_doorbell_index() pins any BO passed as doorbell_handle into the doorbell domain. For a regular BO, TTM moves it with ttm_bo_move_null() and its contents are lost. Since an importer on the same device gets the exporter's GEM object, a client can do this to a buffer another client shared with it. Reject BOs that were not created in the doorbell domain. v2: drop the error message, use a local abo variable (Christian) (cherry picked from commit f7497bbc19db4821c62b9d97b31c9086feb2d917)

    linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hwe linux-azure linux-gcpOperating systems
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  3. CVE-2026-98996

    Not ratedEPSS 0.17%Fix available

    fs: don't silently unmount busy mounts

    In the Linux kernel, the following vulnerability has been resolved: fs: don't silently unmount busy mounts The propagate_mount_busy() helper exists to decide whether a synchronous can suceed. It does that by looking at the copies of the victims in the mounts its parent propagates to. One of those functions from propagation hell. It skips a copy that has child mounts except for the case of a single child mount covering the copy's root. That algorithm used to be exact. It isn't anymore. Originally only childless copies were unmounted during propagation. And 1064f874abc0 ("mnt: Tuck mounts under others instead of creating shadow/side mounts.

    linux linux linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hweOperating systems
    • Update to 4.10
    • Update to 4.12
    • Update to 4.13
    • Update to 4.2
    • Update to 4.5
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  4. CVE-2026-98995

    High · CVSS 7.8EPSS 0.16%Fix available

    namespace: reset the old parent's ->overmount in mnt_change_mountpoint()

    In the Linux kernel, the following vulnerability has been resolved: namespace: reset the old parent's ->overmount in mnt_change_mountpoint() __umount_mnt() resets ->overmount of the parent when it unmounts the mount that overmounts it. mnt_change_mountpoint() doesn't. It moves the mount to its new parent and leaves the old one pointing at it. For a mount that is moved beneath in attach_recursive_mnt() that doesn't matter. The new mount has already reset ->overmount of the old parent by the time the old top mount is moved onto it. It matters for reparent() though. propagate_umount() moves a surviving overmount onto the first ancestor that

    linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hwe linux-azure linux-gcpOperating systems
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  5. CVE-2026-98994

    Not ratedEPSS 0.16%Fix available

    statmount: read the parent of an unmounted mount under mount_lock

    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 c

    linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hwe linux-azure linux-gcpOperating systems
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  6. CVE-2026-98993

    High · CVSS 7.8EPSS 0.18%Fix available

    namespace: don't inherit MNT_UMOUNT in clone_mnt()

    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

    linux linux linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hweOperating systems
    • Update to 4.1
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  7. CVE-2026-98992

    Not ratedEPSS 0.17%Fix available

    namespace: don't copy an unmounted mount tree

    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

    linux linux linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hweOperating systems
    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  8. CVE-2026-98991

    High · CVSS 7.8EPSS 0.16%Fix available

    namespace: queue a mount only once for mount notifications

    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, rep

    linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hwe linux-azure linux-gcpOperating systems
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  9. CVE-2026-98990

    Not ratedEPSS 0.18%Fix available

    namespace: check a submount for references right before unmounting it

    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

    linux linux linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hweOperating systems
    • Update to 4.10
    • Update to 4.11
    • Update to 4.2
    • Update to 4.5
    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  10. CVE-2026-98989

    Not ratedEPSS 0.17%Fix available

    namespace: check a recursive bind mount for mount namespace loops

    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

    linux linux linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hweOperating systems
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  11. CVE-2026-98988

    High · CVSS 8.8EPSS 0.16%Fix available

    namespace: keep covered mounts covered in OPEN_TREE_NAMESPACE

    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_

    linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hwe linux-azure linux-gcpOperating systems
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  12. CVE-2026-98987

    Not ratedEPSS 0.17%Fix available

    namespace: look at the topmost mount for a mount namespace file

    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 existin

    linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hwe linux-azure linux-gcpOperating systems
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  13. CVE-2026-98986

    Not ratedEPSS 0.17%Fix available

    namespace: remove the fsnotify marks of a mount namespace in process context

    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,

    linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hwe linux-azure linux-gcpOperating systems
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  14. CVE-2026-98985

    Not ratedEPSS 0.17%Fix available

    namespace: check the mounts before reading their parents in pivot_root()

    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

    linux linux linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hweOperating systems
    • Update to 4.1
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  15. CVE-2026-98984

    Not ratedEPSS 0.17%Fix available

    dcache: don't put a mountpoint on a dentry that's being removed

    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 det

    linux linux linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hweOperating systems
    • Update to 4.10
    • Update to 4.11
    • Update to 4.2
    • Update to 4.5
    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  16. CVE-2026-98983

    Not ratedEPSS 0.16%Fix available

    unshare: don't drop active namespace references that were never taken

    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:

    linux linux linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hweOperating systems
    • Update to 5.16
    • Update to 6.13
    • Update to 6.19
    • Update to 6.2
    • Update to 6.7
    • Update to 7.1
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  17. CVE-2026-98982

    High · CVSS 7.8EPSS 0.16%Fix available

    namespace: don't let a pseudo dentry become the root of a mount

    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

    linux linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hwe linux-azureOperating systems
    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  18. CVE-2026-98981

    High · CVSS 8.8EPSS 0.16%Fix available

    namespace: unhash a dentry before detaching the mounts on it

    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.

    linux linux linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hweOperating systems
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  19. CVE-2026-98980

    High · CVSS 8.8EPSS 0.18%Fix available

    namei: don't reveal overmounted entries in refwalk

    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 specifical

    linux linux linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hweOperating systems
    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  20. CVE-2026-98979

    Not ratedEPSS 0.17%Fix available

    namespace: refuse an automount below a mount that is in no namespace

    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 userspac

    linux linux linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hweOperating systems
    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

Check your server

Check your installed stack and versions against the current vulnerability feeds.

Check your server →