DF-0823: hammer2_xop_helper cleanup/create mismatch — UAF on multi-chain PFS unmount

Summary

hammer2_xop_helper_create double-allocates xop_groups (no NULL check) when called a second time from hammer2_pfsalloc (vfsops.c:589) after a SLAVE chain joins a mounted PFS cluster. hammer2_xop_helper_cleanup then stops only MASTER-indexed threads (pfs_nmasters instead of nchains), leaving SLAVE threads alive when kfree(xop_groups) frees the backing memory. The orphan threads access freed heap → kernel panic.

Reproduction

# As root on the DragonFlyBSD guest:
./trigger_v2.sh

The trigger creates a 2-chain hammer2 PFS (1 MASTER + 1 SLAVE), does I/O, then unmounts — triggering the cleanup loop mismatch and the orphan-thread UAF.

Expected results

Fix

Two changes in sys/vfs/hammer2/hammer2_admin.c (see fix.diff):

1. Guard xop_groups allocation in hammer2_xop_helper_create — only allocate if xop_groups == NULL, preventing the double-alloc leak and thread orphaning
2. Fix cleanup loop — change pfs_nmasters to cluster.nchains, matching the create loop's range so ALL threads (MASTER + SLAVE) are stopped before kfree

Both changes are required. See VERDICT.md for the full analysis.

DF-0823: hammer2_xop_helper cleanup/create mismatch — UAF on multi-chain PFS unmount

Verdict: REPRODUCED (live kernel panic) — FIX VALIDATED

Severity: High (kernel UAF → panic on default GENERIC with INVARIANTS) Impact: panic — confirmed by live reproduction on DragonFly 6.5-DEVELOPMENT #0 CWE: CWE-416 (Use-After-Free)

Root cause (TWO bugs working together)

Bug 1: hammer2_xop_helper_create double-allocates xop_groups (memory leak + thread orphan)

hammer2_xop_helper_create (hammer2_admin.c:426) unconditionally allocates pmp->xop_groups:

pmp->xop_groups = kmalloc(hammer2_xop_nthreads * sizeof(hammer2_xop_group_t), ...);

It does NOT check if xop_groups is already allocated. This function is called from THREE sites: 1. hammer2_mount_helper (vfsops.c:1708) — during mount, when nchains may be 1 2. hammer2_xop_start_except (admin.c:492) — lazily, guarded by has_xop_threads == 0 3. hammer2_pfsalloc (vfsops.c:589) — unconditionally when pmp->mp || nchains >= 2

When a multi-chain PFS forms (MASTER on device A, SLAVE chain joins from device B): - Call #1 (at mount, nchains=1): allocates xop_groups_A, creates thread[0] - Call #3 (when SLAVE joins, nchains=2): overwrites pmp->xop_groups with xop_groups_B (new allocation), creates thread[0]+thread[1] in xop_groups_B

The old xop_groups_A is leaked, and old thread[0] running in xop_groups_A is orphaned — it continues running, accessing memory the kernel no longer tracks.

Bug 2: hammer2_xop_helper_cleanup stops only MASTER-indexed threads

hammer2_xop_helper_cleanup (hammer2_admin.c:461) iterates pfs_nmasters:

for (i = 0; i < pmp->pfs_nmasters; ++i) {   // only MASTER chains

pfs_nmasters counts only HAMMER2_PFSTYPE_MASTER chains (vfsops.c:536-542), while the CREATE loop uses cluster.nchains (all chain types). For 1 MASTER + 1 SLAVE: nchains=2, pfs_nmasters=1. Cleanup stops thread[0] (MASTER), then kfree(xop_groups) (admin.c:468) frees xop_groups_B while thread[1] (SLAVE) is still running.

Combined effect

After umount of a multi-chain PFS: 1. Cleanup stops only MASTER threads in xop_groups_B → SLAVE thread[1] orphaned 2. kfree(xop_groups_B) frees backing memory under surviving thread[1] 3. Orphan thread[1] continues in hammer2_primary_xops_thread (admin.c:1148): - Reads thr->flags from freed heap (line 1159) - atomic_cmpset_int(&thr->flags, ...) writes freed heap (lines 1213, 1243) - xop->desc->storage_func(...) dereferences function pointer via freed data (line 1220) 4. Additionally, old thread[0] in leaked xop_groups_A is still running and accesses the PMP structure which may also be freed → secondary UAF

Live reproduction

The trigger (trigger_v2.sh) creates two vn-backed hammer2 devices, creates a MASTER PFS on device A and a matching SLAVE PFS on device B, mounts both so the SLAVE chain joins the MASTER's PMP (nchains=2), does I/O, then unmounts.

Panic signature (serial console, unpatched kernel #0)

Fatal trap 12: page fault while in kernel mode
fault virtual address    = 0xfffff8011a1d5558
fault code               = supervisor write data, page not present
instruction pointer      = 0x8:0xffffffff8095da89
current process          = Idle
current thread           = pri 12 (CRIT)

Stopped at      hammer2_primary_xops_thread+0x2d9:      lock xaddl      %edx,0x81558(%rsi)

The lock xaddl %edx,0x81558(%rsi) is an atomic operation within the orphaned hammer2_primary_xops_thread. The page at the target address was freed by kfree(xop_groups) and unmapped, causing the page-not-present fault.

Trigger sequence

1. Create two vn-backed hammer2 images, newfs_hammer2 each
2. Mount vn0@DATA → create MASTER PFS "testpfs" on vn0
3. Mount vn0@testpfs → PMP created (nchains=1), xop_helper_create call #1
4. Mount vn1@DATA → hammer2_update_pmps finds SLAVE testpfs with matching clid → adds chain to PMP (nchains=2) → xop_helper_create call #3 (overwrites xop_groups!)
5. Create SLAVE PFS on vn1 with matching clid
6. I/O on /mnt/test to spin up XOP threads
7. umount /mnt/h2b (vn1@DATA) — mount_count > 0 → pfsfree_scan skipped → SLAVE chain stays
8. umount /mnt/test (vn0@testpfs) — xop_helper_cleanup: stops thread[0] only (pfs_nmasters=1), kfree(xop_groups_B) → orphan threads survive
9. umount /mnt/h2a (vn0@DATA) — device cleanup triggers pfsfree_scan which frees the PMP → old orphan threads access freed PMP/xop_groups → PANIC

Fix (two changes, both required)

Change 1: Guard xop_groups allocation in hammer2_xop_helper_create

-   pmp->xop_groups = kmalloc(hammer2_xop_nthreads *
-                 sizeof(hammer2_xop_group_t),
-                 M_HAMMER2, M_WAITOK | M_ZERO);
+   if (pmp->xop_groups == NULL) {
+       pmp->xop_groups = kmalloc(hammer2_xop_nthreads *
+                     sizeof(hammer2_xop_group_t),
+                     M_HAMMER2, M_WAITOK | M_ZERO);
+   }

This prevents the double allocation: on the second call, existing xop_groups is reused, and only missing threads (for new chain indices) are created.

Change 2: Fix cleanup loop to match create loop's range

-   for (i = 0; i < pmp->pfs_nmasters; ++i) {
+   for (i = 0; i < pmp->iroot->cluster.nchains; ++i) {

This ensures ALL thread columns (MASTER, SLAVE, etc.) are stopped before kfree.

Both changes are required. Change 1 alone still leaves the cleanup loop mismatch (thread[1] created but not stopped). Change 2 alone doesn't prevent the double allocation leak (old threads still orphaned).

Fix validation

The two-fix kernel (sha256=e5fd2095...) was validated with trigger_v2.sh: all three unmounts completed, the 20s wait completed, and the guest remained alive and healthy 45+ seconds post-umount (well past the 30s tsleep interval). The serial console shows no panic, trap, or DDB prompt.