CVE-2026-99052

What it actually does

Failure to set SECURITY_LSM_NATIVE_LABELS on SB_INITIALIZED superblocks in selinux_set_mnt_opts causes nfs_get_root to clear NFS_CAP_SECURITY_LABEL on reused NFSv4 mounts, silently disabling per-file SELinux labeling for all mounts sharing the superblock.

Why it matters to the business

Organizations lose mandatory per-file access controls on NFSv4 filesystems after a second mount, allowing processes to read or write labeled data without SELinux enforcement and increasing risk of unauthorized data access or tampering.

How an attack unfolds

An attacker with network access to an NFSv4 export that uses security_label mounts the share, triggers a second mount via sget_fc reuse, and benefits from the cleared NFS_CAP_SECURITY_LABEL flag so that subsequent file operations bypass SELinux checks on both the new and original mounts.

How to fix it

Apply the upstream kernel patch that sets SECURITY_LSM_NATIVE_LABELS on both SE_SBINITIALIZED early-exit paths in selinux_set_mnt_opts when SECURITY_FS_USE_NATIVE is active; rebuild and deploy the fixed kernel on all affected systems.

How to confirm the fix worked

Mount an NFSv4 security_label export twice on a patched kernel, verify SECURITY_LSM_NATIVE_LABELS remains set in kern_flags, and confirm NFS_CAP_SECURITY_LABEL stays enabled on the nfs_server after the second mount.

Typical attack path

1. Identify NFSv4 export configured with security_label
2. Perform initial mount to initialize the superblock
3. Trigger second mount of the same export so sget_fc returns the existing superblock
4. Observe selinux_set_mnt_opts early exit without setting SECURITY_LSM_NATIVE_LABELS
5. nfs_get_root clears NFS_CAP_SECURITY_LABEL on the shared nfs_server
6. Access files without per-file SELinux labeling enforcement

How to detect it

Review kernel logs for repeated sget_fc and selinux_set_mnt_opts calls on the same NFS superblock, monitor for sudden loss of NFS_CAP_SECURITY_LABEL in nfs_server structures, and inspect audit logs for file accesses that should have been denied by SELinux labels but were permitted.

What your security team should do

• Prioritize patching Linux kernels that contain the selinux NFS mount logic within the CISA remediation window if applicable
• Audit all NFSv4 clients for repeated mounts of security_label exports and restrict mount privileges until fixed
• Add kernel configuration checks for SELinux and NFSv4 security_label support into baseline scanning