Re: [SECURITY] nfsd: fix null dereference in nfsd4_setattr for deleg timestamp attrs

On Sat, Jun 13, 2026, at 4:24 AM, Nikol Kuklev wrote:
> When a SETATTR request includes FATTR4_WORD2_TIME_DELEG_ACCESS or
> FATTR4_WORD2_TIME_DELEG_MODIFY in the attribute bitmap, nfsd4_setattr()
> sets deleg_attrs=true and calls nfs4_preprocess_stateid_op() to validate
> the stateid.
>
> If the client supplies the NFSv4 "one stateid" (all-0xFF bytes),
> check_special_stateids() returns nfs_ok without populating the output
> nfs4_stid pointer, because the special-stateid path in
> nfs4_preprocess_stateid_op() jumps to done: with s==NULL, and the
> "if (s)" block that would set *cstid is skipped. The local variable `st`
> remains NULL.
>
> Back in nfsd4_setattr(), the if (deleg_attrs) block then unconditionally
> dereferences st->sc_type (at offset 4 from NULL), causing a kernel oops.
>
> This is remotely triggerable by any NFSv4 client: send COMPOUND [PUTROOTFH,
> SETATTR(ONE_STATEID, {bmval2=FATTR4_WORD2_TIME_DELEG_ACCESS, ...})].
> No authentication, delegation, or prior state is required.
>
> Fix by adding a NULL check before the dereference. A special stateid is
> not a delegation stateid, so the existing nfserr_bad_stateid return value
> is already correct; we only need to guard the pointer dereference itself.
>
> Fixes: 7e13f4f8d27dc02fb88666f603c53ca749d56f92 ("nfsd: handle delegated
> timestamps in SETATTR")
> Cc: [email protected]
> Assisted-by: Claude:claude-sonnet-4-6
> Signed-off-by: Nikol Kuklev <[email protected]>
> ---
>  fs/nfsd/nfs4proc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> v1 -> v2: Resend as inline patch per maintainer request; no code changes.
>
> diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
> --- a/fs/nfsd/nfs4proc.c
> +++ b/fs/nfsd/nfs4proc.c
> @@ -1251,7 +1251,7 @@ nfsd4_setattr(struct svc_rqst *rqstp, struct
> nfsd4_compound_state *cstate,
>   if (deleg_attrs) {
>   status = nfserr_bad_stateid;
> - if (st->sc_type & SC_TYPE_DELEG) {
> + if (st && (st->sc_type & SC_TYPE_DELEG)) {
>   struct nfs4_delegation *dp = delegstateid(st);
>
>   /* Only for *_ATTRS_DELEG flavors */
> -- 
> 2.39.0

This appears to be your very first submission to the Linux kernel.
I don't see your email in the commit history nor does a lore
search find it. So I'm going to provide some friendly feedback.

The above snippet still does not apply.

In particular, note the whitespace damage in the diff body --
all the tabs are gone.

Please carefully review the below documents explaining how to
prepare your patches and configure your email client to submit
contributions to the Linux kernel:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/email-clients.rst

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst

Maintainers are few and contributions are many. We rely on
scripts and automation to make the individual chores easy and
not overwhelming. When you submit a patch that does not follow
the guidelines above, we have to take time to massage your
submission. For many maintainers, that means they won't bother
to apply it at all, even if your patch is valid.

Since this is your first submission and it is only a one-line
change, I hand-rolled it and applied it to the nfsd-testing
branch.

Next time, please carefully observe our posting guidelines so
this process goes smoothly for you and for us.


>> Thank you for the bug report. Unfortunately the attachment does
>> not apply using "git apply". Please resend the patch inline. See:
>>
>> Documentation/process/email-clients.rst — "Email clients info for Linux."
>>
>> Lines 21-26 state: patches are submitted via email "preferably as inline
>> text in the body of the email." Attachments are "generally frowned upon
>> because it makes quoting portions of the patch more difficult in the patch
>> review process," and where accepted must use content-type text/plain.
>>
>> This doc then covers per-client configuration (Mutt, Alpine, Claws,
>> Evolution, Kmail, Thunderbird, etc.) to send patches inline without
>> mangling whitespace.
>>
>> Related companion docs:
>>   - Documentation/process/submitting-patches.rst — overall patch
>> submission guidance
>>   - Documentation/process/applying-patches.rst — the receiving end


-- 
Chuck Lever