DF-3103 — embedded-ICB read uses unvalidated l_ea/l_ad: wild OOB heap read

What

Two cooperating defects:

1. udf_vget() (sys/vfs/udf/udf_vfsops.c:527) computes the file-entry copy size as size = UDF_FENTRY_SIZE + fe->l_ea + fe->l_ad in wrapping 32-bit int arithmetic from fully attacker-controlled disk fields, then kmalloc(size) + bcopy. Crafted l_ea/l_ad wrap the sum to a small value (e.g. 176 + 0x1000 + 0xFFFFF150 = 0x100000200 → int 0x200) so the M_UDFFENTRY allocation is only 512 bytes while the on-disk fields stay huge in the copied structure.
2. The embedded-ICB path of udf_readatoffset() (sys/vfs/udf/udf_vnops.c:1037-1039) then does *data = &fentry->data[l_ea]; *size = l_ad; with no bounds check and no offset handling. With the wrapped fields: *data = 4272 bytes into a 512-byte allocation, *size = (int)0xFFFFF150 = -5936, which udf_read()'s uiomove(data, size, uio) (:403) receives as (size_t)-5936 → it happily moves uio_resid bytes of kernel heap from far past the allocation into the user's buffer.

Also demonstrated with l_ea = 0x40000000 (file EMB2): *data lands ~1 GB past the object; uiomove()'s fault handling turns the unmapped wild read into EFAULT — proving the kernel dereferences the wild pointer.

Related pass-1 finding: DF-0880 covers the bcopy source over-read at the same udf_vget site; this finding is the distinct vnops sink: the integer-wrap → undersized allocation → &fentry->data[l_ea] + negative *size → sign-extended uiomove chain in udf_readatoffset()/udf_read().

Reproduce

./run.sh     # mounts the crafted image (root), then as uid 1001:
             #  - 3x read(EMB, 96)   -> 96 OOB heap bytes each
             #  - read(EMB, 1024/4096)
             #  - read(EMB2, 96)     -> EFAULT (wild pointer +1GB)

Expected (stock kernel)

read() returned 96 bytes from embedded file (requested 96)
DF3103_LEAK_CONFIRMED: 96 bytes copied from kernel heap at
  fentry->data[0x1000] (~3.7KB past a 512-byte M_UDFFENTRY allocation)
...
read(96) failed: Bad address        <- EMB2 (l_ea=0x40000000)

Patched kernel (fix.diff: vget validation + embedded-path offset handling): open /mnt/EMB: Invalid argument — the malformed file entry is rejected before any allocation or read.

Fix validation

See DF-3102/fix_validate.sh + df31xx_combined_fix.diff (shared driver for DF-3102/3103/3104); fix_run.log excerpt in this directory.

DF-3103 — VERDICT

Status: REPRODUCED (leak / wild-pointer read) — crafted UDF image mounted by root gives any unprivileged user an out-of-bounds kernel-heap read (and a provably wild pointer dereference) via plain open()+read().

Root cause chain

sys/vfs/udf/udf_vfsops.c:527-530:

    size = UDF_FENTRY_SIZE + fe->l_ea + fe->l_ad;      /* wraps in u32/int */
    unode->fentry = kmalloc(size, M_UDFFENTRY, M_WAITOK | M_ZERO);
    bcopy(bp->b_data, unode->fentry, size);

Crafted FE (icbtag.flags & 7 == 3, embedded data): l_ea = 0x1000, l_ad = 0xFFFFF150 → sum 0x100000200 → size = 0x200 → a 512-byte allocation that still carries the huge raw fields.

sys/vfs/udf/udf_vnops.c:1037-1039 (embedded path of udf_readatoffset):

        fentry = node->fentry;
        *data = &fentry->data[fentry->l_ea];   /* fentry + 176 + 4096 */
        *size = fentry->l_ad;                  /* (int)0xFFFFF150 = -5936 */

No validation of l_ea/l_ad against the allocation, no offset handling, no negative-size guard. udf_read() (:401-403) passes both to uiomove(data, size, uio); the negative int length sign-extends to a huge size_t, so uiomove moves uio_resid (user-chosen) bytes from fentry + 4272 — ~3.7 KB past the 512-byte M_UDFFENTRY object.

Reproduction (run.log)

Crafted image: EMB FE at partition-sector 3 with the fields above, inf_len = 0x10000; EMB2 FE with l_ea = 0x40000000, l_ad = 0xC0000140 (same 512-byte wrap). Runs as su maxx (uid 1001):

• read(EMB, 96) ×3: 96 bytes returned each time from kernel heap past the allocation (DF3103_LEAK_CONFIRMED ×3, deterministic).
• read(EMB, 1024) and read(EMB, 4096): same, no fault — the 512-byte malloc zone is backed by large slabs, so the overread stays mapped.
• read(EMB2, 96): EFAULT (Bad address) — uiomove faulted reading fentry->data[0x40000000] (1 GB past the object); DF's copy-fault handling converted the kernel-mode wild read into EFAULT instead of a panic. This is direct proof the kernel dereferenced the attacker-chosen wild offset.

A "correct" kernel would have rejected this file entry outright (an FE is one block; l_ea + l_ad cannot legitimately reach 2^32) — see fix.

Impact

• Crafted-media heap OOB read with attacker-chosen offset (l_ea fully controlled: any offset up to 4 GB past a small heap object) and attacker-chosen length (read count). Deterministic leak of kernel heap; an unmapped choice yields EFAULT (or, on kernels without the copy-fault guard, a kernel page fault/panic → DoS).
• Read primitive only — no write, so no direct uid=0 chain from this bug alone. Combined with DF-0831-style write primitives on the same read-only-image attack surface, it provides the info-leak half of an exploit pair (heap layout disclosure).

Fix validation (fix.diff)

• udf_vget(): reject l_ea/l_ad that don't fit in one logical block (bsize - UDF_FENTRY_SIZE), which kills the wrap and the DF-0880 bcopy over-read at once.
• udf_readatoffset() embedded path: FreeBSD-style offset handling (*data += offset; *size -= offset; / *size = 0 past EOF).
• udf_read(): break on size == 0 so a short embedded file cannot spin the loop.

With the patched module (fix_run.log, same image, same PoC):

--- DF-3103 on patched kernel (expect open EMB to fail) ---
open /mnt/EMB: Invalid argument
--- DF-3103 EMB2 on patched kernel (expect open to fail) ---
open /mnt/EMB2: Invalid argument

No allocation, no read, clean EINVAL — behavior eliminated at the root.

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.