All of lore.kernel.org
 help / color / mirror / Atom feed
From: rtm@csail.mit.edu
To: Chuck Lever <chuck.lever@oracle.com>, Jeff Layton <jlayton@kernel.org>
Cc: linux-nfs@vger.kernel.org
Subject: buffer overrun in nfsd4_store_cache_entry()
Date: Sat, 04 Oct 2025 09:53:08 -0400	[thread overview]
Message-ID: <91299.1759585988@localhost> (raw)

A client can cause nfsd4_store_cache_entry() to write beyond the end
of slot->sl_data[] here:

        base = resp->cstate.data_offset;
        slot->sl_datalen = buf->len - base;
        if (read_bytes_from_xdr_buf(buf, base, slot->sl_data, slot->sl_datalen))

The demo below does this by sending a CREATE_SESSION with

  maxresp_sz = 64
  maxresp_cached = 80

The result is that the next request that includes a SEQUENCE causes
nfsd4_encode_operation() to decide that the response will be too
large, and to return just an error response to the SEQUENCE. Then
nfsd4_store_cache_entry() decides to cache the result, because
nfsd4_cache_this() (really nfsd4_is_solo_sequence()) returns true. But
the maxresp_cached=80 caused nfsd4_alloc_slot() to allocate slots with
"size" of zero, so that slot->sl_data[] has no space. But
nfsd4_store_cache_entry() is not aware of the true size of sl_data[].

On my setup the problem is detected by the slub redzone debug mechanism
when I shut down nfsd, with rpc.nfsd 0.

# cat /etc/exports
/tmp 127.0.0.1(rw,subtree_check,pnfs)
# wget http://www.rtmrtm.org/rtm/nfsd185f.c
# cc nfsd185f.c
# ./a.out
...
[Right Redzone overwritten] 0xffff888103f65200-0xffff888103f65207 @offset=4608. First byte 0x0 instead of 0xcc
=============================================================================
BUG kmalloc-96 (Tainted: G        W          ): Object corrupt
-----------------------------------------------------------------------------
Allocated in 0x2700003500000001 age=12934 cpu=2 pid=1118
BUG: unable to handle page fault for address: ffff888105768000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 3801067 P4D 3801067 PUD 43f902067 PMD 43f8d6067 PTE 800ffffefa897020
Oops: Oops: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
CPU: 11 UID: 0 PID: 1325 Comm: rpc.nfsd Tainted: G        W           6.17.0-09936-gcbf33b8e0b36-dirty #34 PREEMPT(voluntary)
Tainted: [W]=WARN
Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021
RIP: 0010:stack_trace_print+0x23/0x60
Call Trace:
 <TASK>
 stack_depot_print+0x48/0x50
 print_track+0x42/0x70
 print_tracking+0x3e/0x70
 object_err+0x9a/0x2d0
 check_bytes_and_report+0x11a/0x140
 check_object+0x1b7/0x340
 free_to_partial_list+0x1c6/0x570
 ? free_session_slots+0x8a/0x140
 ? free_session_slots+0x8a/0x140
 __slab_free+0x21e/0x3c0
 ? __pfx_schedule_timeout+0x10/0x10
 ? free_session_slots+0x8a/0x140
 kfree+0x2b1/0x350
 free_session_slots+0x8a/0x140
 free_client+0x86/0x150
 __destroy_client+0x246/0x290
 nfs4_state_shutdown_net+0x1da/0x3c0
 nfsd_destroy_serv+0x11a/0x1b0
 nfsd_svc+0x1da/0x300
 write_threads+0xec/0x1b0
 ? __pfx_write_threads+0x10/0x10
 nfsctl_transaction_write+0x4a/0x80
 vfs_write+0xf8/0x470
 ? putname+0x5e/0x80
 ksys_write+0x70/0xf0
 __x64_sys_write+0x18/0x20
 x64_sys_call+0x7d/0x20f0
 do_syscall_64+0xa4/0x280
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Robert Morris
rtm@mit.edu


             reply	other threads:[~2025-10-04 13:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-04 13:53 rtm [this message]
2025-10-04 16:39 ` buffer overrun in nfsd4_store_cache_entry() Chuck Lever

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=91299.1759585988@localhost \
    --to=rtm@csail.mit.edu \
    --cc=chuck.lever@oracle.com \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.