DF-2622 — slice = label[-1] reads one byte below devstr[] on empty/'@'-only mount specs

• Cited: sys/vfs/hammer2/hammer2_vfsops.c:1012-1020 (hammer2_vfs_mount)

What this pack contains

Build

Guest (root): cc -O -o mnt2622 mnt2622.c

Run (as root in the guest)

./mnt2622 '@' /mnt/h2x     # devstr="@"  -> label==devstr -> devstr[-1] OOB read
./mnt2622 ''  /mnt/h2x     # devstr=""   -> label==devstr -> devstr[-1] OOB read

Expected

• Console prints hammer2_mount: device="" label="<BOOT|ROOT|DATA>" — the chosen label encodes the class of the stack byte read below devstr[] ('a'→BOOT, 'd'→ROOT, anything else→DATA; ~1.6-bit oracle). Mount then fails ENOENT (empty device) — the OOB read has already happened.
• Instrumented kernel prints the actual byte: observed 0x00 on one call and 0xff on the very next — live stack garbage below the array, varying with stack history (proof the read is out-of-bounds of any valid object).
• Fixed kernel: identical user-visible behavior (label=DATA default), devstr[-1] never dereferenced.

Threat: one-byte stack OOB read on the mount path; the only externally visible consequence is the console label choice. Requires mount privilege to trigger; console is typically privileged. Low severity as filed — confirmed, no meaningful disclosure boundary crossed.

DF-2622 VERDICT

Status: reproduced (one-byte stack OOB read confirmed live; observable impact: ~1.6-bit console oracle only). Confidence: certain.

Root cause (line-precise)

sys/vfs/hammer2/hammer2_vfsops.c:1007-1020
    label = strchr(devstr, '@');                       /* :1007 */
    if (label && ((label + 1) - devstr) > done) { ... EINVAL }
    if (label == NULL || label[1] == 0) {
        char slice;
        if (label == NULL)
            label = devstr + strlen(devstr);   /* ""    -> label==devstr */
        else
            *label = '\0';                     /* "@"   -> label==devstr */
        slice = label[-1];                      /* :1020  OOB READ        */

devstr is the 80-byte stack array char devstr[MNAMELEN] (vfsops.c:929). Two reachable inputs make label == devstr at :1020:

• volume string exactly "@" — strchr finds index 0, label[1]==0 (the NUL), *label='\0' ⇒ devstr becomes "" and label==devstr;
• volume string "" — label==NULL ⇒ label = devstr+0.

In both cases label[-1] = devstr[-1] reads one byte below the array — stale kernel-stack data. The byte's class is then disclosed on the console via the kprintf at :1037 (device="" label=…: 'a'→BOOT, 'd'→ROOT, else→DATA).

Reachability: confirmed with a direct mount("hammer2", mp, 0, &info) carrying info.volume = "@" / "" (the copyin at vfsops.c:989 accepts both; the guard at :1008 does not reject them; nothing earlier in sys_mount rejects an empty from-spec). Root privileges (or vfs.usermount=1) required to trigger — same precondition class as every mount-spec bug.

Observed

1. Stock kernel #0 (run_stock.log + console_excerpts.txt [A]): both inputs reach :1020; console shows device="" label="DATA" and the mount then fails ENOENT via hammer2_init_devvp("").
2. Instrumented kernel #1 (console_excerpts.txt [B]): * volume="" → label==devstr=1 devstr[-1]=0x00 * volume="@" → label==devstr=1 devstr[-1]=0xff The byte below devstr differs between two consecutive mount(2) calls — it is uninitialized stack memory, not any valid object. Neither value mapped to 'a'/'d' so the label printed DATA both times; the oracle is real (had the stale byte been 0x61/0x64, BOOT/ROOT would print and the mount would search for that PFS).
3. In-bounds reference behavior captured for the same code path: boot root mount devstr="vbd0s1d" → label[-1]='d' → ROOT (the feature working as intended), and /dev/vn0@ → label[-1]='0' → DATA.

Impact (honest ceiling)

One byte of kernel stack is read out of bounds; only its 3-way class (~1.6 bits) reaches the console, which the same (privileged) user who triggered the mount can see. No memory content is returned to userland, no corruption. Low severity as filed — correct.

Fix

-       slice = label[-1];
+       if (label > devstr)
+           slice = label[-1];
+       else
+           slice = 0;  /* empty device: no slice letter */

Empty device now selects the default (DATA) without the read; the BOOT/ROOT slice-letter convenience keeps working for real devices.

Fix validation (kernel #2)

'@' and '' mounts: same ENOENT failure, same label="DATA" console line, and by construction devstr[-1] is never dereferenced (label > devstr guard). No behavior change for valid specs (root mount still selects ROOT via in-bounds 'd').