p PatchFirst

PatchFirst · Vulnérabilités récentes

Vulnérabilités de la pile Systèmes d’exploitation · Page n° 72

Vulnérabilités publiées pour Systèmes d’exploitation au cours des 30 derniers jours : 6567. Présentes dans le catalogue KEV : 4.

RSS ↗ JSON ↗
Filtrer les vulnérabilités
Systèmes d’exploitation

Vulnérabilités : 160309

  1. CVE-2026-98983

    Non évaluéeEPSS 0,16%Correctif disponible

    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-hwe-edge linux-aws-5.0 linux-aws-5.3 linux-azure linux-azure-5.3 linux-azure-edge linux-gcpSystèmes d’exploitation
    • Mettez à jour vers 5.16
    • Mettez à jour vers 6.13
    • Mettez à jour vers 6.19
    • Mettez à jour vers 6.2
    • Mettez à jour vers 6.7
    • Mettez à jour vers 7.1
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  2. CVE-2026-98982

    Élevée · CVSS 7.8EPSS 0,16%Correctif disponible

    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-hwe-edge linux-aws-5.0 linux-aws-5.3 linux-azure linux-azure-5.3 linux-azure-edge linux-gcp linux-gcp-5.3Systèmes d’exploitation
    • Mettez à jour vers 6.12.113-1
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  3. CVE-2026-98981

    Élevée · CVSS 8.8EPSS 0,16%Correctif disponible

    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-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hwe linux-azureSystèmes d’exploitation
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  4. CVE-2026-98980

    Élevée · CVSS 8.8EPSS 0,18%Correctif disponible

    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-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hwe linux-azureSystèmes d’exploitation
    • Mettez à jour vers 6.12.113-1
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  5. CVE-2026-98979

    Non évaluéeEPSS 0,18%Correctif disponible

    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-hwe-edge linux-aws-5.0 linux-aws-5.3 linux-azure linux-azure-5.3 linux-azure-edge linux-gcpSystèmes d’exploitation
    • Mettez à jour vers 6.12.113-1
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  6. CVE-2026-98978

    Élevée · CVSS 8.4EPSS 0,17%Correctif disponible

    namespace: never expire a locked mount

    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/hid

    linux linux linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hweSystèmes d’exploitation
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  7. CVE-2026-98977

    Non évaluéeEPSS 0,18%Correctif disponible

    namespace: handle mount locking for automounts correctly

    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

    linux linux linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hweSystèmes d’exploitation
    • Mettez à jour vers 3.9
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  8. CVE-2026-98976

    Élevée · CVSS 7.8EPSS 0,14%Correctif disponible

    namespace: keep the lock on a mount that a propagated copy is moved beneath

    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'

    linux linux linux linux-hwe-edge linux-aws-5.0 linux-aws-5.3 linux-azure linux-azure-5.3 linux-azure-edge linux-gcp linux-gcp-5.3 linux-gke-4.15Systèmes d’exploitation
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  9. CVE-2026-98975

    Élevée · CVSS 7.8EPSS 0,16%Correctif disponible

    xfs: stop exchanging reflink flags when exchanging mappings

    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-r

    linux linux linux linux linux linux-azure linux-aws-hwe linux-azure linux-gcp linux-hwe linux-hwe-edge linux-oracleSystèmes d’exploitation
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  10. CVE-2026-98974

    Élevée · CVSS 7.8EPSS 0,16%Correctif disponible

    xfs: fix exchange-range-to-eof file size exchange

    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 t

    linux linux linux linux linux-hwe-edge linux-aws-5.0 linux-aws-5.3 linux-azure linux-azure-5.3 linux-azure-edge linux-gcp linux-gcp-5.3Systèmes d’exploitation
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  11. CVE-2026-98973

    Non évaluéeEPSS 0,16%Correctif disponible

    drm/bridge: Fix unlocked list_del in drm_bridge_add()

    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.

    linux linux linux linux-hwe-edge linux-aws-5.0 linux-aws-5.3 linux-azure linux-azure-5.3 linux-azure-edge linux-gcp linux-gcp-5.3 linux-gke-4.15Systèmes d’exploitation
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  12. CVE-2026-98972

    Non évaluéeEPSS 0,16%Correctif disponible

    cgroup/cpuset: Don't access cpuset_cgrp_subsys.root in is_in_v2_mode()

    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

    linux linux linux linux linux linux-azure linux-aws-hwe linux-azure linux-gcp linux-hwe linux-hwe-edge linux-oracleSystèmes d’exploitation
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  13. CVE-2026-98971

    Non évaluéeEPSS 0,17%Correctif disponible

    gpio: exar: initialize the ID before registering its cleanup

    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.

    linux linux linux linux linux linux-hwe-edge linux-aws-5.0 linux-aws-5.3 linux-azure linux-azure-5.3 linux-azure-edge linux-gcpSystèmes d’exploitation
    • Mettez à jour vers 6.12.113-1
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  14. CVE-2026-98970

    Non évaluéeEPSS 0,18%Correctif disponible

    drm/vc4: Free the BO cache size list on teardown

    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.

    linux linux linux linux linux linux-azure linux-aws-hwe linux-azure linux-gcp linux-hwe linux-hwe-edge linux-oracleSystèmes d’exploitation
    • Mettez à jour vers 6.12.113-1
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  15. CVE-2026-98969

    Non évaluéeEPSS 0,18%Correctif disponible

    net/sched: em_text: reject unterminated algo before autoload

    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() w

    linux linux linux linux linux linux linux-aws linux-azure linux-lts-xenial linux linux-aws linux-aws-hweSystèmes d’exploitation
    • Mettez à jour vers 6.12.113-1
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  16. CVE-2026-98968

    Élevée · CVSS 8.1EPSS 0,53%Correctif disponible

    amt: send the relay's General Query directly from the receive path

    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_direc

    linux linux linux linux linux linux-hwe-edge linux-aws-5.0 linux-aws-5.3 linux-azure linux-azure-5.3 linux-azure-edge linux-gcpSystèmes d’exploitation
    • Mettez à jour vers 6.12.113-1
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  17. CVE-2026-98967

    Non évaluéeEPSS 0,18%Correctif disponible

    cxgb4/ch_ktls: disable softirqs around tid_list erases

    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

    linux linux linux linux linux linux-hwe-edge linux-aws-5.0 linux-aws-5.3 linux-azure linux-azure-5.3 linux-azure-edge linux-gcpSystèmes d’exploitation
    • Mettez à jour vers 5.10.273
    • Mettez à jour vers 5.13
    • Mettez à jour vers 6.12.113-1
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  18. CVE-2026-98966

    Non évaluéeEPSS 0,16%Correctif disponible

    bonding: fix the program leak when XDP is replaced

    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.

    linux linux linux linux linux linux-hwe-edge linux-aws-5.0 linux-aws-5.3 linux-azure linux-azure-5.3 linux-azure-edge linux-gcpSystèmes d’exploitation
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  19. CVE-2026-98965

    Élevée · CVSS 7.5EPSS 0,53%Correctif disponible

    ice: Restore Ordered MMIO Writes for Tx Doorbells

    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 guarant

    linux linux linux linux-hwe-edge linux-aws-5.0 linux-aws-5.3 linux-azure linux-azure-5.3 linux-azure-edge linux-gcp linux-gcp-5.3 linux-gke-4.15Systèmes d’exploitation
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  20. CVE-2026-98964

    Élevée · CVSS 7.5EPSS 0,61%Correctif disponible

    nvmet: use the local P2P device on metadata allocation failure

    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.

    linux linux linux linux linux linux-hwe-edge linux-aws-5.0 linux-aws-5.3 linux-azure linux-azure-5.3 linux-azure-edge linux-gcpSystèmes d’exploitation
    • Mettez à jour vers 5.10.273
    • Mettez à jour vers 5.13
    • Mettez à jour vers 6.12.113-1
    • Mettez à jour vers 7.2.11-1
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

Vérifiez votre serveur

Comparez votre pile et les versions installées aux bases de vulnérabilités actuelles.

Vérifiez votre serveur →