F-4.5: SELinux/Smack Label Bypass via NFS (CVE-2024-46695)¶
Classification¶
- Severity: Info
- CVSS Vector: Network / Low Complexity / Requires Root on NFS Client
- Affected Versions: Linux kernel before fix (2024)
- CVE: CVE-2024-46695
- Prerequisite: Root on NFS client +
root_squash(default), NFS-exported filesystem with SELinux/Smack
Summary¶
A vulnerability in the Linux kernel's NFS server allows a root user on an NFS client to modify SELinux or Smack security labels on files stored on NFS filesystems, even when root_squash is enabled. This bypasses the security module's permission checks because nfsd_setattr() calls security_inode_setsecctx() which internally uses __vfs_setxattr_noperm() — explicitly skipping permission verification.
Technical detail¶
Root cause¶
The code path for setting security contexts on NFS-exported files:
The _noperm variant assumes the caller has already verified permissions. But nfsd_setattr()'s permission checks are incomplete — they don't cover security label modifications.
Exploitation¶
A root user on the NFS client (squashed to nobody by root_squash) can still modify security labels because the label-setting code path bypasses the squash mechanism:
# On NFS client as root (squashed to nobody for normal ops)
# But security label changes go through the _noperm path:
chcon -t httpd_sys_content_t /mnt/nfs/sensitive_file
# Succeeds despite root_squash — the SELinux label is modified on the server
This allows: - Relabeling files to make them accessible to specific SELinux domains - Removing restrictive labels to bypass mandatory access control - Changing Smack labels to elevate access in Smack-enforced environments
Fix¶
The kernel fix replaces __vfs_setxattr_noperm() with __vfs_setxattr_locked() in the security_inode_setsecctx() path, which performs proper permission checks including respecting squash mappings.
Impact¶
- Bypass mandatory access control (SELinux, Smack) on NFS-exported filesystems
- Partial bypass of root_squash — security labels can be modified even when UID 0 is squashed
- Requires root on client — not a remote-only attack, but combined with NFS UID spoofing, any user can be root on their own client
Detection¶
- Monitor for unexpected
security.selinuxxattr changes on NFS-exported files - Audit
nfsdoperations that modify extended attributes - Compare SELinux labels against policy baselines
Remediation¶
- Patch the kernel — fixed in Linux kernel (check your distribution's advisory)
- Use Kerberos (
sec=krb5) — eliminates the trust-the-client model - Restrict
root_squashis not sufficient — this CVE bypasses it - Monitor xattr changes on NFS-exported filesystems