DF-0842 — Missing sliding-window allocation in inflate updatewindow()

Severity: Medium (local DoS / NULL-pointer-write kernel panic) CWE: CWE-476 (NULL Pointer Dereference) File: sys/vfs/hammer2/zlib/hammer2_zlib_inflate.c (vendored zlib inflate) Kernel: DragonFly 6.5-DEVELOPMENT, X86_64_GENERIC (HAMMER2 is the root filesystem)

The bug

HAMMER2 ships a vendored copy of zlib whose inflate never allocates the sliding window. state->window is set to Z_NULL in inflateInit2_() (:200) and is only ever referenced by kfree() (:174, :1047) and by updatewindow() (:382, :389, :392) — no kmalloc() exists for it anywhere in the file. Upstream zlib 1.2.8 has an explicit if (state->window == Z_NULL) state->window = ZALLOC(...) block inside updatewindow(); that block was dropped when zlib was vendored into HAMMER2. (The sibling hammer2_zlib_deflate.c:254 does correctly kmalloc() its window, confirming the asymmetry.)

When inflate() is driven with a stream that produces output but exits before the CHECK trailer (e.g. truncated input, or output buffer exhaustion mid-decode), the inf_leave guard at :1018-1019 is TRUE and calls updatewindow(), which zmemcpy()s through state->window == NULL → write to virtual address 0x0 → fatal page fault (trap 12).

Reachability (unprivileged)

read(2) of a HAMMER2 file whose on-disk block is ZLIB-compressed reaches hammer2_strategy_read_completion() (hammer2_strategy.c:458-484) → hammer2_decompress_ZLIB_callback() (:229, calls inflate(&strm, Z_FINISH) at :257). A malformed block (e.g. a ZLIB stream that decompresses past the 16 KB output buffer, or a truncated stream) triggers the NULL-window write. The root filesystem of the audit guest is itself HAMMER2, so this code path is live in the default GENERIC kernel. Realistic precondition (per the audit threat model): an admin mounts / makes mountable an attacker-controlled HAMMER2 image; the unprivileged user then reads the malformed file.

Reproduction

Two independent triggers, both confirmed against the unpatched #0 kernel:

1. Deterministic harness (df0842_harness.c + Makefile, build.sh/run.sh)

A kernel module that calls the real in-kernel z_inflate* symbols (the exact functions used by hammer2_strategy.c:257) on a 20-byte truncated zlib stream that decodes ~1.8 KB of output before the input is exhausted. kldload → fatal trap 12, fault VA = 0x0, memcpy+0xfa.

2. Real unprivileged filesystem-image trigger (make_crafted_image.py)

A HAMMER2 image is built with setcomp zlib + setcheck none; a data block's ZLIB stream is replaced with one that decompresses to 200 KB (≫ the kernel's 16 KB output buffer). cat <file> as the unprivileged maxx user panics the kernel at the identical RIP (memcpy+0xfa, VA = 0x0). See make_crafted_image.py for the generator and VERDICT.md for the full reachability chain.

Build / run

# harness (deterministic):
ssh dfbsd     # root
cd /root/DF-0842 && make SYSDIR=/usr/src/sys KERNBUILDDIR=/usr/obj/usr/src/sys/X86_64_GENERIC
kldload ./df0842_harness.ko     # unpatched: panic; fixed: prints "NO PANIC"

# real unprivileged trigger:
# host: python3 make_crafted_image.py base.img crafted.img
# guest(root): vnconfig + mount crafted.img, chmod a+rX
# guest(maxx): cat /h2mnt/zd/big.bin        # unpatched: panic; fixed: clean read

Impact

NULL-pointer-write at a fixed address (page 0 is unmapped in the kernel) → local denial of service (kernel panic). No escalation chain: the fault is a write to VA 0x0 which cannot be redirected to an attacker-controlled page. On a default GENERIC kernel (INVARIANTS ON) the panic is immediate.

Fix

fix.diff restores the missing allocation block in updatewindow(), matching upstream zlib 1.2.8 (using kmalloc(..., C_ZLIB_BUFFER_INFLATE, M_INTWAIT) to mirror the existing inflate-state and deflate-window allocations). Validated: on the patched #1 kernel both triggers behave gracefully (no panic); the malformed block yields a handled decompression error (HAMMER2 ZLIB: Fatal error during decompression.) instead of a crash.

DF-0842 — VERDICT

Verdict: REPRODUCED (local DoS / NULL-pointer-write panic), fix VALIDATED

Status: reproduced · Impact: panic (local DoS) · Confidence: certain Class: CWE-476 NULL Pointer Dereference (missing allocation, vendored zlib)

Root cause (confirmed by source trace + two live reproductions)

HAMMER2's vendored zlib inflate (sys/vfs/hammer2/zlib/hammer2_zlib_inflate.c) never allocates the sliding window state->window:

• inflateInit2_() sets state->window = Z_NULL (hammer2_zlib_inflate.c:200).
• inflateReset2() may also reset it to Z_NULL (:175).
• The only other references to state->window are kfree() (:174, :1047) and the writes inside updatewindow() (:382, :389, :392).
• There is no kmalloc() / ZALLOC() for state->window anywhere in the file (grep -n 'window' hammer2_zlib_inflate.c shows only NULL sets, frees, and the derefs). Upstream zlib 1.2.8 has an explicit if (state->window == Z_NULL) { state->window = ZALLOC(...); } block inside updatewindow() — this block was lost when zlib was vendored into HAMMER2. The header claims ZLIB_VERSION "1.2.8" (hammer2_zlib.h:42) but the code is not: the allocation was dropped. The sibling hammer2_zlib_deflate.c:254 does correctly kmalloc() its own window, confirming the asymmetry is a vendoring defect, not an intentional omission.

The comment at :352 ("If window does not exist yet, create it") and :541 ("goto inf_leave will create one and copy") document the intent — but the code never creates it.

Trigger mechanism

updatewindow() is called from the inf_leave path of inflate() when:

/* hammer2_zlib_inflate.c:1018-1019 */
if (state->wsize || (out != strm->avail_out && state->mode < BAD &&
        (state->mode < CHECK || flush != Z_FINISH)))
    if (updatewindow(strm, strm->next_out, out - strm->avail_out)) { ... }

On the first inflate() call state->wsize == 0, so the first clause is FALSE. With flush == Z_FINISH (the HAMMER2 caller, hammer2_strategy.c:257), the guard reduces to "output was produced AND mode < CHECK". CHECK/DONE/BAD/MEM are all >= CHECK (hammer2_zlib_inflate.h:39-44); the decode modes HEAD … LIT are < CHECK. So any stream that produces output but exits before the trailer — truncated input (avail_in exhausted mid-decode) or output-buffer exhaustion (a stream that decompresses past avail_out) — makes the guard TRUE.

updatewindow() then sets wsize/wnext/whave (:374-378) and immediately zmemcpy(state->window + ..., ...) (:382/:389/:392) through state->window == NULL → write to virtual address 0x0 → fatal page fault.

Reachability (unprivileged, default GENERIC)

read(2) as unprivileged user
  -> hammer2_vop_strategy / hammer2_strategy_read     (hammer2_strategy.c)
  -> hammer2_strategy_read_completion                  (hammer2_strategy.c:458)
       switch (HAMMER2_DEC_COMP(focus->bref.methods))
         case HAMMER2_COMP_ZLIB:                       (:480)
  -> hammer2_decompress_ZLIB_callback                  (:229)
       inflateInit(&strm_decompress)                   (:244)  window = NULL
       strm.avail_in  = focus->bytes                   (:253)  on-disk block size
       strm.avail_out = bp->b_bufsize                  (:255)  16 KB
       inflate(&strm_decompress, Z_FINISH)             (:257)
  -> z_inflate()  -> inf_leave (mode<CHECK, output)    (hammer2_zlib_inflate.c:556,1018)
  -> updatewindow()                                    (:366)
  -> zmemcpy(state->window == NULL, ...)               (:382/389/392)
  -> write to VA 0x0 -> fatal trap 12.

HAMMER2 is the root filesystem of the audit guest (vbd0s1d on / (hammer2)) and ships in X86_64_GENERIC (options HAMMER2). The realistic precondition (per the audit threat model) is an admin mounting / making mountable an attacker-controlled HAMMER2 image; the unprivileged user then reads the malformed ZLIB-compressed file. (The sibling finding DF-0265 covered the other zlib copy sys/net/zlib.c via netgraph7_deflate, which is LATENT — not in GENERIC. DF-0842 is in HAMMER2, which IS in GENERIC, so it is live.)

Evidence

Reproduction 1 — deterministic harness (df0842_harness.c)

A kernel module calling the real in-kernel z_inflate* symbols (renamed inflate→z_inflate via hammer2_zlib_zconf.h:50) on a 20-byte truncated zlib stream that decodes ~1.8 KB before the input is exhausted. On the unpatched #0 kernel, kldload produces (from boot.log):

DF-0842: inflateInit_ ret=0 ...; now calling z_inflate(Z_FINISH) on a 20-byte truncated stream
Fatal user address access from kernel mode from kldload at ffffffff80bcac8a
Fatal trap 12: page fault while in kernel mode
fault virtual address      = 0x0
fault code                 = supervisor write data, page not present
instruction pointer        = 0x8:0xffffffff80bcac8a
Stopped at      memcpy+0xfa:    repe movsq      (%rsi),%es:(%rdi)

fault code = supervisor write data confirms it is a WRITE through NULL (the zmemcpy into the unallocated window), and memcpy+0xfa is the zmemcpy (repe movsq writing through %rdi == NULL).

Reproduction 2 — real unprivileged filesystem trigger (make_crafted_image.py)

A 64 MB HAMMER2 image is created (newfs_hammer2), mounted, and a directory is marked hammer2 setcomp zlib + hammer2 setcheck none (so the data block's check is none and its bytes can be freely corrupted without tripping a metadata CRC). A compressible file is written, the image is unmounted, and the ZLIB data block is replaced (host-side, make_crafted_image.py) with a stream that decompresses to 200 KB — far larger than the kernel's 16 KB per-block output buffer. The image is re-mounted, and the unprivileged maxx user runs cat /h2mnt/zd/big.bin:

 Fatal trap 12: page fault while in kernel mode
 cpuid = 0; lapic id = 0
 fault virtual address  = 0x0
 fault code     = supervisor write data, page not present
 instruction pointer    = 0x8:0xffffffff80bcac8a
 current process        = Idle
 Stopped at      memcpy+0xfa:    repe movsq      (%rsi),%es:(%rdi)

The RIP (0xffffffff80bcac8a) and the faulting instruction are byte-identical to the harness panic — confirming both reach the same sink: updatewindow() → zmemcpy(state->window == NULL).

(current process = Idle indicates the fault is in the HAMMER2 xop strategy thread performing asynchronous read completion — exactly hammer2_strategy_read_completion → hammer2_decompress_ZLIB_callback.)

Impact / escalation

A NULL-pointer-WRITE at fixed address 0x0 is a pure local DoS: page 0 is not mapped in the DragonFlyBSD kernel, so the write faults immediately and cannot be redirected to an attacker-controlled page. There is no privilege-escalation chain — the only effect is a kernel panic. (No SMAP/SMEP bypass or slab grooming is relevant here: the primitive is a write to a fixed unmapped address, not a controllable corruption of a live kernel object.)

PoC changes from the (absent) scaffold

There was no finding markdown or PoC scaffold on disk for DF-0842 (only the DB row). The runner authored the entire evidence pack from the DB claim: df0842_harness.c + Makefile + build.sh/run.sh (deterministic harness calling real z_inflate), make_crafted_image.py (real unprivileged filesystem-image trigger), fix.diff, this VERDICT.md, and the logs.

Fix (fix.diff) — VALIDATED

Restores the missing window allocation in updatewindow(), matching upstream zlib 1.2.8, using the kernel allocator style already used for the inflate state (:196) and the deflate window (hammer2_zlib_deflate.c:254):

+    /* if window not allocated yet, allocate it. ... */
+    if (state->window == Z_NULL) {
+        state->window = (unsigned char FAR *)
+                        kmalloc(1U << state->wbits,
+                                C_ZLIB_BUFFER_INFLATE, M_INTWAIT);
+        if (state->window == Z_NULL) return 1;
+    }

Fix validation (Phase 8, built + booted single-fix kernel)

• Baseline (#0, unpatched): both triggers panic (fatal trap 12, VA=0x0, memcpy+0xfa) — harness via kldload; real trigger via unprivileged cat.
• Patched (#1, Sat Jul 11 10:26:05 UTC 2026, built from same source + fix.diff only):
• harness kldload → DF-0842: z_inflate returned -5 (NO PANIC -- window was allocated; bug is absent/fixed). avail_out=6384 total_out=1808, guest stays UP, module loads/unloads cleanly.
• real trigger cat as maxx → CAT_EXIT=0, guest UP, dmesg shows the graceful HAMMER2 ZLIB: Fatal error during decompression. path (hammer2_strategy.c:258-261 handles ret != Z_STREAM_END by bzeroing the buffer) — no NULL deref, no panic.

fix_status = fixed (clean before/after on both triggers).

Note on the allocation flags

The fix uses plain kmalloc(..., M_INTWAIT) (no M_ZERO), matching upstream zlib 1.2.8 and the existing deflate-window allocation. The inflate window is always written via whave/wnext tracking before being read, so uninitialized contents are not leaked in normal operation. (The unrelated info-leak class of DF-0266 concerns the other zlib copy sys/net/zlib.c; if desired, adding M_ZERO here would be defense-in-depth against a future distance-bounds regression, but it is out of scope for this NULL-deref fix.)