CVE-2026-99052 in Linux
Summary
by MITRE • 10/23/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel's Security-Enhanced Linux (SELinux) subsystem contains a logic flaw within the mount option handling mechanism for NFSv4 filesystems that utilize security labels. This vulnerability arises specifically during the remounting or second mounting of an NFSv4 share that was originally exported with the security_label attribute enabled. The core issue lies in how the kernel manages superblock initialization and flag propagation when a shared superblock is reused rather than created anew. When such a filesystem is mounted for the first time, the SELinux subsystem correctly identifies the need to preserve native labeling capabilities by setting the SECURITY_LSM_NATIVE_LABELS flag within the set_kern_flags structure. However, if the same NFSv4 share is subsequently mounted again, the kernel's superblock allocation function sget_fc detects that a matching superblock already exists and returns this existing instance instead of creating a new one.
This reuse of an existing superblock triggers a different code path in the SELinux mount option processing logic compared to initial mounts or cloned options. Specifically, nfs_get_root invokes security_sb_set_mnt_opts on the already-initialized superblock. Because the superblock is marked as SB_INITIALIZED, the selinux_set_mnt_opts function executes an early exit condition designed to prevent redundant initialization work. Unfortunately, this optimization fails to replicate the critical logic required for label preservation. The function does not set SECURITY_LSM_NATIVE_LABELS in *set_kern_flags because it assumes that since the superblock is already initialized, no further configuration changes are necessary. This assumption overlooks the requirement to explicitly maintain or re-establish native labeling flags when processing mount options on a reused superblock context.
The operational impact of this flaw is significant for environments relying on fine-grained access control via SELinux labels on NFS shares. Following the second mount operation, nfs_get_root inspects the kflags and observes that SECURITY_LSM_NATIVE_LABELS is absent from *set_kern_flags. Consequently, it clears the NFS_CAP_SECURITY_LABEL capability flag on the shared nfs_server structure. This action effectively disables per-file security labeling for both the newly mounted instance and any existing mounts of the same share. The result is a silent degradation of security posture where files lose their SELinux context labels during access checks, potentially allowing unauthorized access or violating policy enforcement rules that depend on these specific file attributes.
This issue mirrors a previously identified problem in selinux_sb_clone_mnt_opts which was addressed by commit 3815a245b501. That fix ensured that cloned mount options correctly preserved native labeling flags. The current vulnerability affects the distinct code path taken during standard second mounts, which utilizes sb_set_mnt_opts rather than sb_clone_mnt_opts. To resolve this inconsistency and restore proper security label handling, the selinux_set_mnt_opts function must be updated to check if the superblock was originally configured with SECURITY_FS_USE_NATIVE labeling. If so, it must explicitly set SECURITY_LSM_NATIVE_LABELS in *set_kern_flags even when taking the early exit path for initialized superblocks. This ensures that the native label capability is preserved across all mount scenarios involving reused superblocks.
From a classification perspective, this vulnerability aligns with CWE-940 Improper Verification of Authentication Credentials or more accurately CWE-253 Incorrect Check of Function Return Value if viewed as a failure to properly handle state transitions, but it is best categorized under CWE-671 Failure to Use Specific Mechanism for Required Security Control. In terms of the MITRE ATT&CK framework, this represents a potential weakness in system configuration that could be exploited by an attacker who can trigger repeated mounts or manipulate mount options to bypass SELinux policies, falling under Tactic TA0004 Privilege Escalation and Technique T1548 Abuse Configuration. Mitigation requires applying the kernel patch that corrects the logic within selinux_set_mnt_opts to ensure SECURITY_LSM_NATIVE_LABELS is set appropriately during the initialization phase of reused superblocks for NFSv4 filesystems with security labels enabled. Administrators should verify their SELinux policies and mount configurations are consistent across all instances of shared resources to prevent accidental policy bypasses resulting from this flag clearing behavior.