From: NeilBrown <neilb@ownmail.net>
To: "Linus Torvalds" <torvalds@linuxfoundation.org>,
linux-nfs@vger.kernel.org
Cc: "Rishi Shakya" <rishishakya30@gmail.com>,
security@kernel.org, "Chuck Lever" <chuck.lever@oracle.com>,
"Jeff Layton" <jlayton@kernel.org>
Subject: Re: Authentication Downgrade to AUTH_SYS in NFSv4.2 Inter-Server Copy (nfsd4_interssc_connect)
Date: Sat, 09 May 2026 14:14:00 +1000 [thread overview]
Message-ID: <177830004077.1474915.1115119001196387152@noble.neil.brown.name> (raw)
In-Reply-To: <CAHk-=wjjzAcUYyC4sXdThoDZex129Jmy68ng+JKSriofuSty_Q@mail.gmail.com>
On Sat, 09 May 2026, Linus Torvalds wrote:
> I think this should probably be dealt with in the open. I have cc'd
> the nfsd maintainers, and I forwarded the original to them, but I
> suspect any future discussions should probably be on the appropriate
> lists.
and yet no one sent anything the the appropriate list :-)
Ok this is on the nfs list.
> Subject: Authentication Downgrade to AUTH_SYS in NFSv4.2 Inter-Server
> Copy (nfsd4_interssc_connect)
> To: <security@kernel.org>
>
>
> Dear Linux Kernel Security Team and NFS Maintainers,
>
> I am writing to report a critical authentication downgrade
> vulnerability in the nfsd subsystem of the Linux Kernel. Specifically,
> the vulnerability exists in the handling of NFSv4.2 Inter-Server
> Server-to-Server Copy (SSC) requests.
>
> When a destination server initiates an internal mount to a source
> server via nfsd4_interssc_connect(), it relies on a hardcoded macro
> (NFSD42_INTERSSC_MOUNTOPS) that strictly enforces sec=sys. This
> completely bypasses any Kerberos (GSS-API) or otherwise strict
> security policies enforced by the administrator, allowing an
> unprivileged attacker to mount arbitrary malicious NFS servers with
> uid=0 trust.
This is where you lose me. The above line seems to be meaningless.
The NFS server does not "mount" the target filesystem (from the
malicious NFS server) in the traditional sense. What it does is
activate the NFS client code to talk to that server. This involves
creating an appropriate superblock and other internal data structures
that can be used by nfsd to work with the NFS client code. This uses
the kern_mount() API. The purpose of this API is to activate a
filesystem for kernel-internal use. The file system never appears
in any namespace so no application other than nfsd can ever access it.
All nfsd does is open/read/close a file using a filehandle and stateid
that were supplied by the original client. There is no way that the
"malicious" NFS server can do anything except pass back to nfsd the
contents of some file. There is nothing it can do to affect the
privilege level of any operation at all.
It not inconceivable that the malicious server to return the data in
such a way (block size/speed/whatever) which causes some sort of
denial-of-service to nfsd, but I think that is the worst it could do and
even that seems unlikely.
Your test code only got as far as activating the NFS client. You need to
demonstrate something more than that to demonstrate an exploit.
NeilBrown
>
> Please find the detailed CVE report, technical analysis, and
> proof-of-concept execution logs below.
>
> Vulnerability: NFSv4.2 Inter-Server Copy (SSC) Forced Authentication
> Downgrade (sec=sys) Target: Linux Kernel (fs/nfsd subsystem) Tested
> Version: Linux Kernel 7.1.0-rc2+ (Vulnerability exists in all versions
> supporting NFSv4.2 SSC) Severity: HIGH (Authentication Bypass / Trust
> Boundary Violation)
>
> 1. Executive Summary
> A critical security flaw exists in the Network File System Server
> (nfsd) implementation of the Linux Kernel when handling NFSv4.2
> Inter-Server Server-to-Server Copy (SSC) operations. The
> nfsd4_interssc_connect() function establishes connections to remote
> source servers using a hardcoded mount options string that strictly
> enforces sec=sys (AUTH_SYS).
>
> This hardcoded downgrading of security completely bypasses
> administrative configurations that mandate strict Kerberos (GSS-API)
> authentication. An unprivileged attacker can exploit this by
> instructing the victim's NFS server to copy a file from an
> attacker-controlled remote NFS server. The victim's kernel will
> connect to the malicious server using the weak AUTH_SYS protocol,
> allowing the attacker to spoof arbitrary User IDs (e.g., UID 0 / root)
> and trick the victim's kernel into ingesting malicious payloads or
> leaking sensitive state.
>
> 2. Technical Deep Dive
> The NFSv4.2 protocol introduced the COPY operation (Opcode 60),
> allowing a client to ask a destination server to fetch data directly
> from a source server, avoiding routing the data through the client.
>
> When the Linux kernel (nfsd) receives an inter-server COPY request,
> the execution flow is as follows:
>
> nfsd4_copy() (in fs/nfsd/nfs4proc.c) determines if the copy is inter-server.
> It calls nfsd4_setup_inter_ssc().
> It then invokes nfsd4_interssc_connect().
> Within nfsd4_interssc_connect(), the kernel utilizes the
> vfs_kern_mount() API to mount the remote source server internally. The
> vulnerability lies in the definition of the mount string used for this
> connection.
>
> Vulnerable Code (fs/nfsd/nfs4state.c & fs/nfsd/nfs4proc.c)
> c
> // Hardcoded mount options enforcing AUTH_SYS
> #define NFSD42_INTERSSC_MOUNTOPS "vers=4.2,addr=%s,sec=sys"
> static __be32 nfsd4_interssc_connect(struct nl4_server *nss, struct
> svc_rqst *rqstp,
> struct nfsd4_ssc_umount_item **nsui)
> {
> // ...
> snprintf(raw_data, raw_len, NFSD42_INTERSSC_MOUNTOPS, ipaddr);
>
> // ...
> /* Use an 'internal' mount: SB_KERNMOUNT -> MNT_INTERNAL */
> ss_mnt = vfs_kern_mount(type, SB_KERNMOUNT, dev_name, raw_data);
> // ...
> }
> Because the kernel implicitly trusts the attacker-provided source IP
> address and enforces sec=sys, the malicious server dictates the user
> and group permissions without requiring cryptographic proof, rendering
> any Kerberos configurations on the destination server useless.
>
> 3. Lab Environment Setup
> To isolate and definitively prove this vulnerability, a rigorous
> testing environment was established separating the attacker (Host) and
> the victim (QEMU VM).
>
> Victim VM Kernel: Recompiled from Linux 7.1.0-rc2+ source tree with
> CONFIG_NFSD_V4_2=y and CONFIG_NFSD_V4_2_INTER_SSC=y.
> Victim VM OS: Minimal Debian initrd.
> Attacker Host: Execution of a custom Python XDR script
> (pynfs_ssc_trigger.py) to manually craft and send NFSv4.2 compounds
> over TCP port 20490 (forwarded to VM port 2049).
> 4. Step-by-Step Exploitation & Protocol Hurdles
> Triggering the vulnerable nfsd4_interssc_connect() function required
> navigating several rigid NFSv4 protocol constraints. Here is the
> breakdown of the hurdles faced and how they were bypassed to confirm
> the exploitability of the bug. Note: Bypassing these checks was solely
> for the purpose of demonstrating the hardcoded mount parameter
> execution path using a lightweight script, as opposed to writing a
> full stateful client. A real-world client driver would naturally
> satisfy these constraints.
>
> Hurdle 1: Minorversion Negotiation Rejection
> Issue: Initial attempts to send an NFSv4.2 compound returned 10071
> (NFS4ERR_MINOR_VERS_MISMATCH). The rpc.nfsd userspace daemon
> internally clears minor versions during startup.
> Bypass: We created a dedicated /etc/nfs.conf in the VM with [nfsd]
> vers4.2=y before starting the daemon. This successfully enabled the
> kernel to accept minorversion 2.
> Hurdle 2: Strict Session Context (NFS4ERR_OP_NOT_IN_SESSION)
> Issue: In NFSv4.1+, all operations must occur within a session
> context, requiring an OP_SEQUENCE header. Our raw exploit attempt
> threw error 10071 (which mapped to NFS4ERR_OP_NOT_IN_SESSION
> internally).
> Bypass: To focus purely on validating the sec=sys bug without building
> an entire stateful session manager in Python, we patched the test
> kernel's nfs41_check_op_ordering() function in fs/nfsd/nfs4proc.c to
> return nfs_ok. This allowed us to send raw OP_COPY compounds directly.
> Hurdle 3: Inter-Server Offload & Sync Validation (NFS4ERR_NOTSUPP)
> Issue: The OP_COPY compound returned 10022 (NFS4ERR_NOTSUPP).
> Bypass: Two constraints caused this:
> By default, Linux disables SSC. We explicitly enabled it in the VM via
> echo Y > /sys/module/nfsd/parameters/inter_copy_offload_enable.
> The Linux kernel strictly does not support synchronous inter-server
> copies. We modified our payload to set the ca_synchronous flag to 0
> (FALSE) inside the OP_COPY arguments.
> Hurdle 4: XDR Filehandle Constraints (NFS4ERR_NOFILEHANDLE)
> Issue: After resolving the previous issues, the kernel returned 10020
> (NFS4ERR_NOFILEHANDLE). Analysis of check_if_stalefh_allowed() in
> nfs4proc.c revealed that an OP_COPY explicitly requires the preceding
> operation in the compound to be OP_SAVEFH (Save File Handle).
> Bypass: We modified the exploit payload to inject OP_SAVEFH
> immediately prior to OP_COPY.
> Final Payload Compound Structure: [ OP_PUTFH (Dest_FH) ] -> [
> OP_SAVEFH ] -> [ OP_COPY (Source=Attacker_IP) ]
>
> 5. Final Confirmation & Execution Logs
> With all protocol requirements met, the final exploit script
> successfully bypassed the validation checks and hit the sec=sys
> vulnerable function.
>
> Attacker (Host) Execution Log:
>
> text
> $ python3 pynfs_ssc_trigger.py
> ============================================================
> BUG-006 NFSv4.2 Inter-Server SSC Definitive Trigger v2
> ============================================================
> Target (Victim NFSD) : 127.0.0.1:20490
> Source (Attacker NFS) : 10.0.2.2:2049
> [+] Connected to VM NFSD (vulnerable kernel 7.1.0-rc2)!
> [Step 1] Getting root file handle...
> [+] Root FH obtained (8 bytes): 0100010000000000...
> [Step 4] Sending COPY directly against Root FH with remote source server...
> [*] >>> This triggers nfsd4_interssc_connect() in VM kernel <<<
> [*] Source URL: nfs://10.0.2.2/home/veronica/bot/attacker_share/pwned.txt
> [*] Sending NFSv4.2 COPY with ca_source_server = 10.0.2.2
> ============================================================
> [*] COMPOUND status: 10036 (NFS4ERR_BADXDR - expected after COPY)
> [*] PUTFH status: 0
> [*] COPY status: 0
> [*] COPY error meaning: [!!!] NFS4_OK - COPY SUCCEEDED! BUG-006 CONFIRMED!
> ============================================================
> Victim (VM) Kernel Logs:
>
> text
> [ 838.284931] NFSD BUG006-DBG: received minorversion=2, nfsd_test=1,
> nfsd4_minorversions[2]=1
> [ 861.306957] NFSD BUG006-DBG: received minorversion=2, nfsd_test=1,
> nfsd4_minorversions[2]=1
> The status: 0 (NFS4_OK) returned by the kernel for the OP_COPY block
> conclusively proves that execution successfully reached and executed
> nfsd4_interssc_connect(), triggering the hardcoded sec=sys mount
> against the attacker's server.
>
> 6. Conclusion & Remediation
> The hardcoding of sec=sys in NFSD42_INTERSSC_MOUNTOPS fundamentally
> breaks the security model of NFSv4.2 environments relying on strong
> cryptography (Kerberos).
>
> Proposed Fix: The NFSD42_INTERSSC_MOUNTOPS definition should be
> refactored to dynamically inherit the security parameters (sec=) of
> the existing client session or the specific export policy, rather than
> forcing the weakest denominator (sec=sys). Validations must be added
> to ensure the destination server refuses SSC requests that mandate
> downgrading the negotiated authentication state.
>
> Thank you for your time and dedication to securing the Linux kernel. I
> am available for any questions or to assist in reviewing potential
> patches.
parent reply other threads:[~2026-05-09 4:14 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <CAHk-=wjjzAcUYyC4sXdThoDZex129Jmy68ng+JKSriofuSty_Q@mail.gmail.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=177830004077.1474915.1115119001196387152@noble.neil.brown.name \
--to=neilb@ownmail.net \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=rishishakya30@gmail.com \
--cc=security@kernel.org \
--cc=torvalds@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).