CVE-2026-99052

UnknownEPSS 0.17%

Last modified

CVE-2026-99052 is a vulnerability of currently unknown severity. In the Linux kernel, the following vulnerability has been resolved: selinux: preserve NATIVE_LABELS on already-initialized sb in set_mnt_opts When an NFSv4 filesystem exported with security_label is mounted a second time, sget_fc() returns the existing superblock and nfs_get_root() calls security_sb_set_mnt_opts() again on it. Since the superblock is already SB_INITIALIZED, selinux_set_mnt_opts() takes an early exit without setting SECURITY_LSM_NATIVE_LABELS in *set_kern_flags. EPSS estimates a 0.17% chance of exploitation in the next 30 days.

Description

In the Linux kernel, the following vulnerability has been resolved: selinux: preserve NATIVE_LABELS on already-initialized sb in set_mnt_opts When an NFSv4 filesystem exported with security_label is mounted a second time, sget_fc() returns the existing superblock and nfs_get_root() calls security_sb_set_mnt_opts() again on it. Since the superblock is already SB_INITIALIZED, selinux_set_mnt_opts() takes an early exit without setting SECURITY_LSM_NATIVE_LABELS in *set_kern_flags. nfs_get_root() then sees kflags without SECURITY_LSM_NATIVE_LABELS set and clears NFS_CAP_SECURITY_LABEL on the shared nfs_server, silently disabling per-file labeling for both the new and the original mount. Commit 3815a245b501 ("security/selinux: fix SECURITY_LSM_NATIVE_LABELS on reused superblock") fixed the same problem in selinux_sb_clone_mnt_opts(). The reused-superblock path for a plain second mount now goes through sb_set_mnt_opts rather than sb_clone_mnt_opts, so it needs the same treatment: on both SE_SBINITIALIZED early exits, set SECURITY_LSM_NATIVE_LABELS in *set_kern_flags when the superblock was already using SECURITY_FS_USE_NATVE.

Metrics

EPSS Probability
0.17%

6.2th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= eb9ae686507bc5a5ca78e6b3fbe629cd5cc67864, < 22987d24a159ed7df3cdc9090ca5d61e58df0cac; >= eb9ae686507bc5a5ca78e6b3fbe629cd5cc67864, < 2f0f1f5a3b89c1ed67e39be49d29ee7f5c96e039; >= eb9ae686507bc5a5ca78e6b3fbe629cd5cc67864, < dc579e43b13cb65e55eabaae4f1a950e43567fb1; >= eb9ae686507bc5a5ca78e6b3fbe629cd5cc67864, < a545def625860d4ccedc14fe45e884a62a041cef; >= eb9ae686507bc5a5ca78e6b3fbe629cd5cc67864, < a6da93c625b3557dd23ff6db45d2d1bafeae1565; >= eb9ae686507bc5a5ca78e6b3fbe629cd5cc67864, < 5509d498e1b9edafebd5a60ba3cb9ecfda23dc2b; >= eb9ae686507bc5a5ca78e6b3fbe629cd5cc67864, < c997832414f1d846de0a1fa38d7d4f62ba2ea917; >= eb9ae686507bc5a5ca78e6b3fbe629cd5cc67864, < 28b7260548af3d35773477993ad4e4de41578dd7
LinuxLinux3.11

References

Timeline

Published
Last Modified
Status
Received

Frequently Asked Questions

What is CVE-2026-99052?
In the Linux kernel, the following vulnerability has been resolved: selinux: preserve NATIVE_LABELS on already-initialized sb in set_mnt_opts When an NFSv4 filesystem exported with security_label is mounted a second time, sget_fc() returns the existing superblock and nfs_get_root() calls security_sb_set_mnt_opts() again on it. Since the superblock is already SB_INITIALIZED, selinux_set_mnt_opts() takes an early exit without setting SECURITY_LSM_NATIVE_LABELS in *set_kern_flags. nfs_get_root() then sees kflags without SECURITY_LSM_NATIVE_LABELS set and clears NFS_CAP_SECURITY_LABEL on the shared nfs_server, silently disabling per-file labeling for both the new and the original mount. Commit 3815a245b501 ("security/selinux: fix SECURITY_LSM_NATIVE_LABELS on reused superblock") fixed the same problem in selinux_sb_clone_mnt_opts(). The reused-superblock path for a plain second mount now goes through sb_set_mnt_opts rather than sb_clone_mnt_opts, so it needs the same treatment: on both SE_SBINITIALIZED early exits, set SECURITY_LSM_NATIVE_LABELS in *set_kern_flags when the superblock was already using SECURITY_FS_USE_NATVE.
How severe is CVE-2026-99052?
Severity scoring for CVE-2026-99052 is pending analysis. The EPSS model estimates a 0.17% probability of exploitation in the next 30 days.
How do I fix CVE-2026-99052?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

Are you affected by CVE-2026-99052?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST