CVE-2025-68803
NoneCVSS
—
EPSS
0.4%
Published
Jan 13, 2026
CISA due date
—
Cloudanix analysis
A bug in Linux file-sharing code can cause custom access rules set when creating a file over the network to be ignored, so the file may end up with different permissions than intended.
- Exploitation
- Remote Authenticated
- Attacker needs
- Low Privilege
- Complexity
- Theoretical
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Authorization Bypass
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
NFSv4 file creation in nfsd_create_setattr skips nfsd_setattr when only a POSIX ACL is supplied because nfsd_attrs_valid checks solely for iattr changes and security labels, leaving the requested ACL unapplied to the inode so that subsequent getattr returns a mode-bit-derived default ACL instead of the one specified by the client.
Why it matters to the business
Linux servers exporting NFSv4 shares may silently apply incorrect file permissions on creation, increasing the risk of unintended data exposure or access-control violations for organizations relying on named-principal ACLs.
How an attack unfolds
An NFSv4 client issues a CREATE operation that includes a POSIX ACL containing a named principal; the server’s nfsd_attrs_valid test returns false, nfsd_setattr is bypassed, the ACL is never written, and later ACL retrieval returns only the default derived from mode bits, violating the client’s expectation that the supplied ACL is stored verbatim.
How to fix it
Upgrade the Linux kernel to a fixed release such as 5.10.248 or apply commit c182e1e0b7640f6bcc0c5ca8d473f7c57199ea3d (and equivalent backports) on all affected stable trees; rebuild and reboot NFS servers, then verify the patch is active before re-exporting shares.
How to confirm the fix worked
Confirm the running kernel contains the fix (uname -r or rpm -q kernel), create a test file via NFSv4 while supplying a named-principal ACL, retrieve the ACL, and verify the exact ACL is stored rather than a mode-derived default.
Typical attack path
- Establish NFSv4 mount to a vulnerable Linux server
- Issue CREATE with a POSIX ACL specifying a named principal
- Observe that subsequent GETATTR or GETACL returns only a mode-derived default ACL
- Access or modify the file under permissions that differ from the intended ACL
How to detect it
Review NFS server logs (nfsd, rpc.mountd) for CREATE operations accompanied by ACL attributes, correlate with subsequent GETACL replies that contain only mode-derived entries, and inspect kernel version strings on NFS servers for the presence of the listed fixed commits.
What your security team should do
- Prioritize kernel updates on all NFSv4-exporting systems within the next maintenance window
- Temporarily restrict NFSv4 ACL usage or fall back to mode-bit permissions until patches are applied
- Add kernel version checks to configuration-management and vulnerability-scanning pipelines
- Review NFS share exports and client ACL expectations for compliance impact
The record
In the Linux kernel, the following vulnerability has been resolved: NFSD: NFSv4 file creation neglects setting ACL An NFSv4 client that sets an ACL with a named principal during file creation retrieves the ACL afterwards, and finds that it is only a default ACL (based on the mode bits) and not the ACL that was requested during file creation. This violates RFC 8881 section 6.4.1.3: "the ACL attribute is set as given". The issue occurs in nfsd_create_setattr(), which calls nfsd_attrs_valid() to determine whether to call nfsd_setattr(). However, nfsd_attrs_valid() checks only for iattr changes and security labels, but not POSIX ACLs. When only an ACL is present, the function returns false, nfsd_setattr() is skipped, and the POSIX ACL is never applied to the inode. Subsequently, when the client retrieves the ACL, the server finds no POSIX ACL on the inode and returns one generated from the file's mode bits rather than returning the originally-specified ACL.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|---|---|---|
| Linux | Kernel | 0 | 5.10.248 |
| openSUSE:Leap 16.0 | dtb-aarch64 | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-64kb | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-azure | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-default | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-default-base | 0 | 6.12.0-160000.26.1.160000.2.7 |
| openSUSE:Leap 16.0 | kernel-docs | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-kvmsmall | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-obs-build | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-obs-qa | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-rt | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-source | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-syms | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-zfcpdump | 0 | 6.12.0-160000.26.1 |
Related vulnerabilities
- CVE-2026-23226 In the Linux kernel, the following vulnerability has been resolved: ksmbd: add chann_lock… Also affects Kernel
- CVE-2026-23225 In the Linux kernel, the following vulnerability has been resolved: sched/mmcid: Don't… Also affects Kernel
- CVE-2026-23230 In the Linux kernel, the following vulnerability has been resolved: smb: client: split… Also affects Kernel
- CVE-2026-23224 In the Linux kernel, the following vulnerability has been resolved: erofs: fix UAF issue… Also affects Kernel
- CVE-2026-23227 In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use… Also affects Kernel
- CVE-2026-23223 In the Linux kernel, the following vulnerability has been resolved: xfs: fix UAF in… Also affects Kernel
- CVE-2026-23228 In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak… Also affects Kernel
- CVE-2026-23229 In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add… Also affects Kernel