vfs: reject oversized iovcnt in sys_read/sys_write (fix app-triggerable kernel panic)

[gburd]

Security fix — local DoS (any unprivileged app can panic the kernel).

sys_read()/sys_write() (fs/vfs/vfs_syscalls.cc) summed iov_len over niov entries and only then did assert(niov <= UIO_MAXIOV) before a struct iovec copy_iov[niov] VLA. niov is caller-controlled and reaches here unvalidated from readv/writev/preadv/pwritev/preadv2/pwritev2, io_uring READV/WRITEV(_FIXED), and libaio PREADV/PWRITEV.

Three problems:

1. OSv keeps assert() live in _KERNEL builds (include/api/assert.h: #if defined NDEBUG && !defined _KERNEL), so niov > UIO_MAXIOV → __assert_fail → abort() = whole-VM panic. In a unikernel an app-triggerable panic is a full-system DoS.
2. The summation loop dereferences iov[i] for up to niov entries before the assert → out-of-bounds read.
3. copy_iov[niov] is a VLA sized by the unvalidated count (kernel-stack blowout).

PoC

struct iovec v = {0,0};
readv(open("/f", O_RDONLY), &v, 0x40000000);   // -> assert -> abort() -> VM panic (before this fix)

Also reachable by submitting an IORING_OP_READV SQE with len = 0x40000000.

Fix

Reject niov > UIO_MAXIOV with EINVAL at function entry (before touching iov), matching Linux's EINVAL for an out-of-range iovcnt. Fixes all three issues.

Severity

High (CVSS ~7.1, AV:L/AC:L/PR:L/UI:N/A:H) — trivially reachable kernel panic.

Verified with tst-iovcnt-guard (new): readv/writev with a huge iovcnt now return -1/EINVAL instead of aborting.