DF-4139 — throw_rude_remark() strcpy of a up-to-1024-byte message into

ioctl_reply->msg[256] (up to 4 bytes past the VINUM_CREATE ioctl

buffer), plus a dangling static ioctl_reply after longjmp/remove

Root cause

sys/dev/raid/vinum/vinumconfig.c:108-117:

    if ((ioctl_reply != NULL)
    &&(!(vinum_conf.flags & VF_READING_CONFIG))) {
        kvasnprintf(&text, MSG_MAX, msg, ap);   /* up to 1024 bytes */
        strcpy(ioctl_reply->msg, text);     /* msg is char[256]! */
        ioctl_reply->error = error;

• MSG_MAX is 1024 (vinumconfig.c:90) but the destination is struct _ioctl_reply { int error; char msg[MAX_IOCTL_REPLY]; } with MAX_IOCTL_REPLY 256 in non-VINUMDEBUG builds (vinumio.h:42-45).
• For VINUM_CREATE the reply struct overlays the 1024-byte ioctl buffer (BUFSIZE, vinumio.h:113,116), so strcpy writes at data+4 and a maximally long message (e.g. throw_rude_remark(EINVAL, "Invalid configuration information: %s", token[0]) with a ~988-byte first token) writes 4 + 1024 = 1028 bytes into the kmalloc(1024) buffer — 4 bytes past the end of the kernel heap allocation (sys/kern/sys_generic.c:675 allocates exactly 1024 for this ioctl). The last 3 attacker-controlled characters plus the NUL land in the adjacent kmalloc object.
• Secondary lifetime defect: parse_user_config() clears the static ioctl_reply only on the normal path (vinumconfig.c:1683). When parse_config longjmps out via throw_rude_remark, and after every remove() call (vinumconfig.c:1693 never clears it), the static keeps pointing at the ioctl buffer, which sys_ioctl frees on return. A later throw_rude_remark reached from a different ioctl while another thread holds the config lock (VINUM_ATTACH/DETACH/MOVE paths call give_sd_to_plex/give_sd_to_drive, which throw) then performs a use-after-free write of the message text into the freed 260/1024- byte chunk. (Without the lock held it panics first — see DF-4136.)

Threat

Root/operator via /dev/vinum/control. The 4-byte overflow is small but is a genuine cross-object heap write with chosen ASCII content.

Fix

--- a/sys/dev/raid/vinum/vinumconfig.c
+++ b/sys/dev/raid/vinum/vinumconfig.c
@@ -112,7 +112,7 @@ throw_rude_remark(int error, char *msg,...)
     * it may contain our input parameters
     */
        kvasnprintf(&text, MSG_MAX, msg, ap);
-       strcpy(ioctl_reply->msg, text);
+       strlcpy(ioctl_reply->msg, text, sizeof(ioctl_reply->msg));

and clear the static ioctl_reply = NULL in a setjmp-safe place (e.g. at the top of the VINUM_CREATE error branch in vinumioctl.c and at the end of remove()).

Verification

Skipped live: Low severity (4-byte overflow, root-gated); the dangling static UAF additionally requires a cross-thread lock race. Bounds math is certain from source (MSG_MAX vs MAX_IOCTL_REPLY vs BUFSIZE).