DF-2714 — sendfile(2) hdtr headers: unbounded kernel mbuf allocation

What

sys_sendfile() (sys/kern/uipc_syscalls.c:1617-1642) marshals the sf_hdtr header iovec into an mbuf chain with m_uiomove() before kern_sendfile() performs any validation or socket-buffer accounting. iovec_copyin() only rejects overflow, so the header total may be up to SSIZE_MAX-1 bytes. Every iteration of m_uiomove() allocates mbuf clusters with M_WAITOK (sys/kern/uipc_mbuf.c:2664), bounded only by the global mbuf cluster pool / system memory.

Unlike sendmsg() (whose sosend() self-throttles on ssb_space()), the sendfile header path has no bound at all.

Threat

Any unprivileged local user: fd = any readable file (/etc/passwd), s = any socket (it need not even be valid for sendfile — validation happens after marshalling). Two consequences, both reproduced:

1. Transient: an attacker-chosen volume of kernel mbuf memory (e.g. 56 MB = 80% of the guest's 33,296-cluster pool) is allocated and held for the duration of the copy.
2. Persistent wedge: a request larger than the pool leaves the syscall sleeping uninterruptibly in the objcache allocator (state D3, WCHAN=objcache) while holding every mbuf cluster in the system. kill -9 does not work. Network RX/TX starves system-wide; reboot required.

Reproduce

cc -O2 -o sendfile_hdtr_dos sendfile_hdtr_dos.c
# bounded (watch netstat -m "mbuf clusters in use" during the call):
./sendfile_hdtr_dos 56
# wedge (request > pool; run under a shell you can afford to lose):
./sendfile_hdtr_dos 256

Baseline observations (kernel #0, unpatched): - run.log: peak 26684/33296 mbuf clusters in use during a 56 MB header sendfile that then returns EINVAL. - run.2.log: 256 MB request -> 33494/33296 mbuf clusters in use, process D3 objcache, survives kill -9, syscall never returns.

Patched (fix.diff, kernel #2): both runs return EINVAL immediately; peak cluster sample 256/33296 (idle baseline). fix_run.log.

Fix

Cap header/trailer totals at 1 MB (SF_HDTR_MAXBYTES) before marshalling — see fix.diff (validated).

DF-2714 — VERDICT

Status: REPRODUCED (impact: dos — unprivileged, system-wide, reboot-required)

Narrative

Guest: DragonFly 6.5-DEVELOPMENT, X86_64_GENERIC, 6 CPU, 4 GB RAM, kern.ipc.nmbclusters=33296 (~65 MB of 2 KB clusters).

1. Code path confirmed: sys_sendfile() copies in the sf_hdtr, runs iovec_copyin() on hdtr.headers (sys/kern/uipc_syscalls.c:1625-1628), then m_uiomove(&auio) (line 1637) builds the ENTIRE header mbuf chain with M_WAITOK allocations before kern_sendfile() (line 1645) performs the first validation of the socket (SOCK_STREAM? connected? SSB_PREALLOC?). iovec_copyin() (sys/kern/kern_subr.c:448-494) permits totals up to SSIZE_MAX-1. m_uiomove() (sys/kern/uipc_mbuf.c:2664) loops while (uio_resid > 0) allocating a cluster per iteration. No bound anywhere.
2. Bounded run (run.log, kernel #0): ./sendfile_hdtr_dos 56 as the unprivileged user maxx — netstat -m sampled at 100 ms showed 26684/33296 mbuf clusters in use (80% of the global pool; baseline 256) during the call; the call then returned EINVAL (socket is a plain UDP socket — proof that marshalling precedes validation).
3. Wedge run (run.2.log, kernel #0): ./sendfile_hdtr_dos 256 — after 15 s: 33494/33296 mbuf clusters in use, process state D3 (non-interruptible machine-descheduled) with WCHAN=objcache, sleeping in the objcache allocator for clusters that will never be freed because the wedged syscall itself holds them all. kill -9 was delivered and had no effect (still D3 objcache). The syscall never returned; the guest had to be reset.
4. Contrast with sendmsg(): sosend() checks ssb_space()/ssb_lowat before each mbuf append (sys/kern/uipc_socket.c:1916-1935 region) so a single sendmsg cannot hold more than the socket's send-buffer worth of mbufs; the sendfile header path bypasses all of that.

Root cause (path:line)

• sys/kern/uipc_syscalls.c:1617-1642 (hdtr marshalling before any check)
• sys/kern/uipc_syscalls.c:1637 (m_uiomove on unbounded uio_resid)
• sys/kern/kern_subr.c:455-489 (iovec_copyin allows SSIZE_MAX totals)
• sys/kern/uipc_mbuf.c:2664-2691 (m_uiomove unbounded M_WAITOK loop)

Fix validation

fix.diff adds SF_HDTR_MAXBYTES (1 MB) caps on header and trailer totals right after each iovec_copyin(). Built and installed as kernel #2 (alongside the DF-2713 fix, independent file); re-running the exact PoC: 56 MB and 256 MB requests both return EINVAL immediately, and the peak cluster sample during both runs was 256/33296 — the idle baseline (fix_run.log). Baseline wedge cannot be reproduced on the patched kernel. fix_status: fixed.

Note: on both baseline runs the failing sendfile copied out an uninitialized stack sbytes (printed sbytes=1) — that is the already filed DF-2695, not re-reported here.