From: Chuck Lever <chuck.lever@oracle.com>
To: Jeff Layton <jlayton@kernel.org>, rtm@csail.mit.edu
Cc: NeilBrown <neil@brown.name>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
linux-nfs@vger.kernel.org
Subject: Re: client can crash nfsd4_encode_fattr4() by setting bit 84
Date: Wed, 10 Sep 2025 10:53:47 -0400 [thread overview]
Message-ID: <0f0c9878-b45f-49c1-b9e8-9ee4b830d51e@oracle.com> (raw)
In-Reply-To: <f4b122ca21ca772ea66d2f5b335cb751d116c3dc.camel@kernel.org>
On 9/10/25 10:49 AM, Jeff Layton wrote:
> On Wed, 2025-09-10 at 09:55 -0400, rtm@csail.mit.edu wrote:
>> Entry 84 (and a few neighbors) in nfsd4_enc_fattr4_encode_ops[] is
>> NULL, so if a client sets that bit in an OP_VERIFY bitmask, the server
>> will crash here in nfsd_encode_fattr4():
>>
>> for_each_set_bit(bit, attr_bitmap,
>> ARRAY_SIZE(nfsd4_enc_fattr4_encode_ops)) {
>> status = nfsd4_enc_fattr4_encode_ops[bit](xdr, &args);
>
> Thanks. That looks like a real bug, alright. I think we just need to
> check that nfsd4_enc_fattr4_encode_ops[bit] is non-NULL before calling
> its handler.
>
> Care to propose a patch?
597 #define FATTR4_WORD2_XATTR_SUPPORT BIT(FATTR4_XATTR_SUPPORT -
64)
598 #define FATTR4_WORD2_TIME_DELEG_ACCESS BIT(FATTR4_TIME_DELEG_ACCESS
- 64)
599 #define FATTR4_WORD2_TIME_DELEG_MODIFY BIT(FATTR4_TIME_DELEG_MODIFY
- 64)
600 #define FATTR4_WORD2_OPEN_ARGUMENTS BIT(FATTR4_OPEN_ARGUMENTS -
64)
I think entries for time_deleg_access and time_deleg_modify are missing
in nfsd4_enc_fattr4_encode_ops...
>
>>
>> I've attached a demo:
>>
>> # cc nfsd128b.c
>> # ./a.out
>> ...
>> [ 354.732253] BUG: kernel NULL pointer dereference, address: 0000000000000000
>> [ 354.733355] #PF: supervisor instruction fetch in kernel mode
>> [ 354.734247] #PF: error_code(0x0010) - not-present page
>> [ 354.735053] PGD 0 P4D 0
>> [ 354.735482] Oops: Oops: 0010 [#1] SMP PTI
>> [ 354.736120] CPU: 2 UID: 0 PID: 1459 Comm: nfsd Not tainted 6.17.0-rc4-00231-gc8ed9b5c02a5 #28 PREEMPT(voluntary)
>> [ 354.737664] Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021
>> [ 354.738645] RIP: 0010:0x0
>> [ 354.739087] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
>> [ 354.739677] RSP: 0018:ffffa7a380e0fa20 EFLAGS: 00010293
>> [ 354.739956] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000053
>> [ 354.740327] RDX: 0000000000000014 RSI: ffffa7a380e0fa78 RDI: ffffa7a380e0fc50
>> [ 354.740691] RBP: ffffa7a380e0fc28 R08: 0000000000000001 R09: ffffa7a380e0fa68
>> [ 354.741060] R10: 0000000000000000 R11: 0000000000140000 R12: ffffa7a380e0fc50
>> [ 354.741432] R13: 0000000000000010 R14: 0000000000000054 R15: ffffa36c03bdba00
>> [ 354.741802] FS: 0000000000000000(0000) GS:ffffa36fa6c88000(0000) knlGS:0000000000000000
>> [ 354.742215] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [ 354.742519] CR2: ffffffffffffffd6 CR3: 00000001885a6003 CR4: 00000000003706f0
>> [ 354.742887] Call Trace:
>> [ 354.743030] <TASK>
>> [ 354.743152] nfsd4_encode_fattr4+0x310/0x6b0
>> [ 354.743396] nfsd4_encode_fattr_to_buf+0xb8/0xf0
>> [ 354.743645] ? _nfsd4_verify+0x9a/0x160
>> [ 354.743861] ? _nfsd4_verify+0xd0/0x160
>> [ 354.744072] _nfsd4_verify+0xd0/0x160
>> [ 354.744278] nfsd4_verify+0x9/0x20
>> [ 354.744466] nfsd4_proc_compound+0x39c/0x720
>> [ 354.744701] nfsd_dispatch+0xd2/0x210
>> [ 354.744903] svc_process_common+0x481/0x630
>> [ 354.745130] ? __pfx_nfsd_dispatch+0x10/0x10
>> [ 354.745362] svc_process+0x12c/0x1b0
>> [ 354.745558] svc_recv+0x7d0/0x990
>> [ 354.745738] ? __pfx_nfsd+0x10/0x10
>> [ 354.745929] nfsd+0x8a/0xe0
>> [ 354.746083] kthread+0xf6/0x1f0
>> [ 354.746260] ? __pfx_kthread+0x10/0x10
>> [ 354.746464] ret_from_fork+0x80/0xd0
>> [ 354.746658] ? __pfx_kthread+0x10/0x10
>> [ 354.746859] ret_from_fork_asm+0x1a/0x30
>> [ 354.747069] </TASK>
>>
>> Robert Morris
>> rtm@mit.edu
>
--
Chuck Lever
next prev parent reply other threads:[~2025-09-10 14:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 13:55 client can crash nfsd4_encode_fattr4() by setting bit 84 rtm
2025-09-10 14:49 ` Jeff Layton
2025-09-10 14:53 ` Chuck Lever [this message]
2025-09-10 15:08 ` Jeff Layton
2025-09-10 15:10 ` Chuck Lever
2025-09-10 15:21 ` Jeff Layton
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=0f0c9878-b45f-49c1-b9e8-9ee4b830d51e@oracle.com \
--to=chuck.lever@oracle.com \
--cc=Dai.Ngo@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=rtm@csail.mit.edu \
--cc=tom@talpey.com \
/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