DF-2459 — Re-queued NOP-IN PDU in _nop_in causes bcopy(NULL) in isc_sendPDU

Verdict

REPRODUCED — remote kernel panic (DoS) from a malicious iSCSI target. The bug is a NULL-pointer read (page fault @0x0) inside bcopy/memmove, not a write primitive; no escalation chain applies (Phase 6 read-only hard blocker). Fix validated on a rebuilt module.

Mechanism (trigger → primitive → effect)

1. Same precondition as DF-2460: a privileged user passes a connected iSCSI socket to the kernel via ISCSISETSOC, starting the receiver thread before login (iscsi.c:430).
2. The malicious target sends a NOP-IN PDU (opcode=0x20) with itt = 0xffffffff and ttt != 0xffffffff, and a non-zero AHSLength (e.g. AHSLength=1 ⇒ 4 bytes of AHS).
3. so_recv() (isc_soc.c:387-389) sets pp->ahs_len = bhs->AHSLength*4 and reads the AHS bytes into the mbuf chain pq->mp — it never sets pp->ahs, which stays NULL (from pdu_alloc's memset).
4. _nop_in() (isc_sm.c:195) takes the itt==-1 && ttt!=-1 branch, mutates the BHS into a NOP-OUT (isc_sm.c:217-227) and re-queues the same PDU via isc_qout() (isc_sm.c:228). Because pq->len is non-zero (set by so_recv), isc_qout does not call i_prepPDU (isc_sm.c:309), so the stale pp->ahs_len survives.
5. proc_out() dequeues the NOP-OUT and calls isc_sendPDU() (isc_sm.c:530), whose active (mbuf) implementation does: c if(pp->ahs_len) { /* isc_soc.c:120 -- true */ bcopy(pp->ahs, ..., pp->ahs_len); /* isc_soc.c:125 -- pp->ahs == NULL */ bcopy(NULL, ...) faults reading address 0x0.

Evidence (panic signature, unpatched #0 kernel)

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
fault code      = supervisor read data, page not present
instruction pointer = 0x8:0xffffffff80bca9b5
...
Stopped at      memmove+0xb5:   movl    (%rsi),%edx
db>

memmove (called by bcopy) with %rsi==0 is the bcopy(pp->ahs==NULL,...). Reproduced by mtarget nopin + idrv.

Threat model / privilege boundary

Identical to DF-2460: the attacker is the iSCSI target; the bug fires pre-login, no auth needed; the privileged ISCSISETSOC (root, /dev/iscsi is 0600 root:wheel) is the only thing the victim must do (normal iscontrol usage).

Why no escalation (Phase 6 hard blocker)

NULL-pointer read (bcopy from NULL). No attacker-controlled write destination, no content control, no object reuse — the read-only / no-write hard blocker applies; the only effect is a kernel panic (DoS).

PoC changes

• mtarget.c, idrv.c: same harness as DF-2460; nopin mode sends the 52-byte NOP-IN (opcode=0x20, F=1, AHSLength=1, itt=0xffffffff, ttt=1 + 4 AHS bytes).
• fix.diff (new): in _nop_in's re-queue branch, clear the stale AHS/data length fields (pp->ahs_len=0, pp->ds_len=0, pointers NULL) and force i_prepPDU to re-prepare the outgoing NOP-OUT (pq->len=0).

Fix (fix.diff)

Root cause: a received PDU is re-queued for sending with pp->ahs_len set from the wire but pp->ahs == NULL (AHS lives in pq->mp). The outgoing NOP-OUT keep-alive carries no AHS/data, so the fix drops the stale length fields and lets isc_qout→i_prepPDU recompute pq->len/BHS lengths for the NOP-OUT. Supersedes the finding markdown's proposal (which identified the bcopy(pp->ahs) line; this fixes the root cause at the re-queue site).

Fix validation (rebuilt single module)

• Baseline (unpatched #0): PoC panics — Fatal trap 12 va=0x0 Stopped at memmove+0xb5 (panic.txt).
• Patched module (sha256 f71cd799...): PoC runs clean — idrv reports "still alive after 6s (no panic)", guest up, no panic in serial log.