⬢ DragonFlyBSD Kernel Audit
DF-4509 / verdict.json
← back to finding ↓ download raw 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
{
  "finding_id": "DF-4509",
  "status": "inconclusive",
  "reproduced": 0,
  "impact": "none",
  "confidence": "certain",
  "verdict": "Code-certain queue-discipline defect, hardware-gated: on the ETIMEDOUT path of tw_cli_drain_aen_queue (tw_cl_misc.c:353-356 -> out: label at :379-384) the internal REQUEST_SENSE request is inserted into TW_CLI_FREE_Q while it is still linked in TW_CLI_BUSY_Q (tw_cl_io.c:219) or TW_CLI_PENDING_Q (tw_cl_io.c:204) because the insert macros (tw_cl_share.h:284-296) never unlink; the request is then handed out twice (tw_cli_get_request) while the firmware still owns it and internal_req_data is re-assigned, producing crossed completions, double FREE_Q insertion from two owners and request reuse under live firmware DMA (same class as DF-4335/DF-4274/DF-1814, distinct site in the reset path). Deterministic once the firmware fails to complete the sense within the 60s poll window. Could not be exercised: the audit QEMU guest has no 3ware 9000-series controller (no /dev/twa*, prober exit 2 in run.log), and even on hardware the trigger is a hung controller during reset, not a userspace action. Not a false positive: the state machine analysis in VERDICT.md is deterministic.",
  "exploit_chain": "",
  "evidence": "VERDICT.md (full line-by-line queue-state proof); twa_probe.c + run.log (device-absent diagnosis); fix.diff (git-apply clean against sys/)",
  "kernel_refs": [
    "sys/dev/raid/twa/tw_cl_misc.c:309-386",
    "sys/dev/raid/twa/tw_cl_misc.c:353-356",
    "sys/dev/raid/twa/tw_cl_misc.c:379-384",
    "sys/dev/raid/twa/tw_cl_io.c:199-204",
    "sys/dev/raid/twa/tw_cl_io.c:218-219",
    "sys/dev/raid/twa/tw_cl_share.h:284-296"
  ],
  "poc_changes": "authored fresh: device-presence prober documenting the hardware precondition (no seed existed)",
  "attempts": 1,
  "guest_uname": "DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul  2 06:02:54 UTC 2026  root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC  x86_64",
  "runtime_sec": 12,
  "guest_dirty": 0,
  "build_cmd": "cc -O -o /tmp/twa_probe /root/poc/DF-4509/twa_probe.c",
  "run_cmd": "/tmp/twa_probe",
  "code_hash": "a380d6ff46924cb6195972ee6451f0420ae7eea71e68860355a89058ff231aa0",
  "fix_status": "not_testable",
  "fix_baseline_reproduced": 0,
  "fix_patched_reproduced": 0,
  "fix_verdict": "fix.diff (unlink from BUSY_Q/PENDING_Q before the FREE_Q insert at the out: label) is git-apply clean against the read-only sys/ tree and uses only existing macros (tw_cli_req_q_remove_item, tw_cl.h:305); baseline/patched behaviour could not be compared because no twa controller exists on the guest and the vulnerable path needs a hung firmware to fire.",
  "fix_evidence": "git apply --check findings/poc/DF-4509/fix.diff -> OK; macro/state constants verified against sys/dev/raid/twa/tw_cl.h:59-62,270,305",
  "notes": "Third distinct site of the request-requeue-after-timeout class: DF-4335 (get/set_param, normal operation), DF-4274 (OSL passthru error path), DF-1814 (init_connection). Severity Low: requires local hardware failure (controller hang) + attached twa card; consequence is kernel memory corruption of the drivers static request array. Classes killed for this file in pass 2 (see final report): uninit AEN-packet leak (aen_queue kmalloc is zeroed at tw_cl_init.c:289-291), ioctl-vs-writer AEN race (reader holds gen_lock, writers unlocked phase only tears data), describe_bits/desc[200] bounds (max ~119 bytes), find_aen div-by-zero (max_aens_supported is a compile-time constant 256 from the OSL, not firmware-derived), drain_response_queue unbounded poll (hardware-trust DoS only).",
  "recommended_fix": "At tw_cl_misc.c out: label, tw_cli_req_q_remove_item(req, BUSY_Q or PENDING_Q) when req->state is still BUSY/PENDING before inserting into FREE_Q"
}