DF-3091 — pcbmap() accepts cluster numbers beyond pm_maxcluster

Cross-volume kernel-mediated read AND write through a mounted FAT filesystem, from a crafted FAT chain whose value lies between pm_maxcluster and the reserved range.

Threat model

Crafted media: the attacker controls a disk image / USB stick that a victim mounts (root, or any user with vfs.usermount=1). The crafted FAT volume claims a small slice of the device; a file's FAT chain then references cluster numbers that pass pcbmap()'s only guards (pm_fatmask + reserved-range) but exceed pm_maxcluster, so cntobn() maps them to device blocks beyond the volume — e.g. into neighboring partitions on the same medium. Reads disclose those bytes; writes persist attacker data there.

Build (in the DragonFly guest, as root)

cd /root/df3091
cc -O -o craftfat16 craftfat16.c     # see build.sh / build.log

Run

sh run.sh                            # baseline: expect the two markers below

Success criteria (stock kernel):

1. TEST 1 read: dd if=/mnt/df3091/LEAK.TXT bs=512 skip=1 count=1 returns DF3091-OUT-OF-VOLUME-MARKER — bytes from device block 7020, which lies beyond the 4 MiB claimed volume (blocks 0..8191) on the 8 MiB device.
2. TEST 2 write: writing PWNED-BY-DF3091-CROSS-VOLUME-WRITE through the mount changes the raw image at device block 7020 (outside the volume).

Fixed kernel (fix.diff, single-fix rebuild): TEST 1 returns no data (EIO), TEST 2 fails with Input/output error, the out-of-volume marker sector is unchanged, and the in-volume control file still reads correctly. See run.2.log (fresh baseline), fix_run.log (fresh fixed-kernel run), and the pass-1 logs (run.log, run.log.patched).

Artifacts

See manifest.json for the full list.

DF-3091 VERDICT — pcbmap() maps out-of-range FAT chain values beyond the mounted volume (cross-volume read + write)

Status: REPRODUCED (fresh re-verification on stock kernel 2026-10-12) Fix VALIDATED on a single-fix rebuilt kernel (fixed 2026-10-12).

Root cause (line-accurate, current tree)

pcbmap() walks a file's FAT chain and only stops at the reserved range — sys/vfs/msdosfs/msdosfs_fat.c:183-193:

    for (; i < findcn; i++) {
        /*
         * Stop with all reserved clusters, not just with EOF.
         */
        if ((cn | ~pmp->pm_fatmask) >= CLUST_RSRVD)   /* :187 */
            goto hiteof;
        ... cn = <next FAT entry>; cn &= pmp->pm_fatmask;

After the loop, any non-EOF value is mapped unconditionally — sys/vfs/msdosfs/msdosfs_fat.c:225-230:

    if (!MSDOSFSEOF(pmp, cn)) {
        ...
        if (bnp)
            *bnp = cntobn(pmp, cn);                    /* :230 */

There is no cn > pmp->pm_maxcluster check anywhere in pcbmap(), although every other FAT function has one (fatentry :485, clusteralloc :565/:632, chainalloc :759, chaincontig :823, extendfile :897/:906/:950). pm_maxcluster itself is the lesser of the BPB-derived cluster count and the FAT's entry capacity — clamped at mount in sys/vfs/msdosfs/msdosfs_vfsops.c:486-490 (our image's mount prints Warning: number of clusters (8172) exceeds FAT capacity (5120) on the serial console and clamps to 5119). A FAT chain value between pm_maxcluster+1 and CLUST_RSRVD-1 (FAT16: 0xfff5) therefore passes every check in pcbmap and is translated by cntobn(cn) = firstcluster + (cn-2)*SecPerClust into a device block far beyond the volume the mount claimed — but still inside the backing device, so the bread/bwrite the caller performs hits real, out-of-volume device sectors.

Reproduction (this run, fresh vm.sh reset with-src boot, stock kernel)

Crafted image (craftfat16.c): 8 MiB device, 32 KiB..4 MiB FAT16 volume (HugeSectors=8192 → pm_maxcluster=5119 after the capacity clamp), file LEAK.TXT with chain [2, 7000]: cluster index 1 = phantom cluster 7000 → device block 7020 (byte 3,594,240), 3.4 MiB beyond the volume end. A marker is planted at that out-of-volume block.

• TEST 1 (read): dd if=$MNT/LEAK.TXT bs=512 skip=1 count=1 returned DF3091-OUT-OF-VOLUME-MARKER:... — the kernel read device bytes from beyond the mounted volume into a file. Out-of-volume disclosure.
• TEST 2 (write): 34 bytes written through the mount at file offset 512 changed the raw image at device block 7020 to PWNED-BY-DF3091-CROSS-VOLUME-WRITE. Out-of-volume tampering that survives unmount (persisted to the medium).
• Control: CTRL.TXT (honest in-volume chain) reads its in-volume data — the bug does not disturb normal operation.

Logs: run.2.log (this run), run.log (pass-1, identical result).

Impact (honest)

This is a filesystem containment break, not kernel memory corruption: the primitive reads/writes device sectors of the same backing device that are outside the mounted volume — i.e. other partitions/slices of attacker-supplied media (or, with vfs.usermount=1, of any device the unprivileged mounter may access). Precondition: root mounts the crafted image (default vfs.usermount=0) or usermount is enabled — matching the finding's PR:H. Realistic ceiling: disclosure of other partitions' data and silent tampering with it (integrity). Not a uid=0 chain by itself on this guest; the audited severity (High, C:H/I:H) stands.

Fix validation (single-fix kernel, this run)

fix.diff (authored pass-1, re-verified): clamp cn > pm_maxcluster → hiteof both inside the walk (msdosfs_fat.c:187) and after FAT assembly (after :226), plus a bio_offset == NOOFFSET guard in msdosfs_write (msdosfs_vnops.c:728) so unmappable clusters can't enter the delayed-write path.

Applied to a clean-source snapshot, make nativekernel KERNCONF=X86_64_GENERIC (~19 min), make installkernel, reboot (DragonFly 6.5-DEVELOPMENT #1: Mon Oct 12 12:07:23 UTC 2026), exact same run.sh:

• TEST 1: no marker bytes returned (read fails EIO — no out-of-volume data reaches userspace).
• TEST 2: dd: /mnt/df3091/LEAK.TXT: Input/output error, 0 bytes transferred; the out-of-volume marker sector is byte-identical before/after.
• In-volume control file unaffected; mount/umount clean.

Baseline reproduced / patched not reproduced → fix_status: fixed. Pass-1 had already observed the same (run.log.patched).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.