DF-2463 — NULL-deref panic in so_input: pdu_alloc retry uses M_NOWAIT then derefs NULL

Verdict

INCONCLUSIVE — confirmed latent NULL-deref, but the live trigger is impractical to reproduce in this guest. The bug is unambiguously present in the source (the retry uses M_NOWAIT despite the comment "OK to WAIT", and the subsequent pq->pdu.ipdu.bhs = sp->bhs deref at isc_soc.c:545 is unconditional); reproducing the actual panic requires pdu_alloc(M_NOWAIT) to fail twice in a row while a PDU is being received, a condition the receiver's freepdu recycling defeats under all realistic workloads. The fix is straightforward and compiles.

Mechanism (confirmed by source)

// sys/dev/disk/iscsi/initiator/isc_soc.c:540-545
pq = pdu_alloc(sp->isc, M_NOWAIT);
if(pq == NULL) { // XXX: might cause a deadlock ...
     debug(3, "out of pdus, wait");
     pq = pdu_alloc(sp->isc, M_NOWAIT);  // OK to WAIT     <-- M_NOWAIT, not M_WAITOK
}
pq->pdu.ipdu.bhs = sp->bhs;                               <-- unconditional NULL deref

• Author intent (the trailing comment "OK to WAIT") was to block on the retry via M_WAITOK, which makes objcache_get() sleep until a PDU is available and never returns NULL. The code instead re-uses M_NOWAIT.
• pdu_alloc() (iscsivar.h:296) checks the per-session freepdu TAILQ first, then falls back to objcache_get(isc->pdu_zone, wait). The pdu_zone is an unbounded malloc-backed objcache (iscsi.c:721, objcache_malloc_alloc).
• If the freepdu list is empty and kmalloc(sizeof(pduq_t), M_NOWAIT) fails (system low-memory), pdu_alloc returns NULL on both calls; line 545 then dereferences pq → kernel NULL-deref panic.

Why it did not reproduce (reachability hard blocker)

Two genuine preconditions must coincide, and the receiver's design defeats the first under all normal workloads:

1. The per-session freepdu TAILQ must be empty. pdu_alloc serves from it before ever calling the objcache. For every received PDU the receiver dispatches it through ism_recv() and the opcode handler frees the pdu immediately — _nop_in (isc_sm.c:195) frees at isc_sm.c:255, _reject/_async/_r2t/_read_data all call pdu_free() at the end of their handler. So in steady-state reception each pdu is recycled back onto the freepdu list before the next pdu_alloc; the list almost never drains, and the objcache M_NOWAIT path is almost never taken.
2. System memory pressure must make kmalloc(M_NOWAIT) fail. Even with the objcache path reached, small-slab allocations (pduq_t is a few hundred bytes) are served from existing slab objects / per-CPU magazines and succeed long after the page allocator is strained.

I engineered genuine memory pressure in the guest (unprivileged memhog allocating + touching memory with vm.swap_enabled=0, driving vm.stats.vm.v_free_count down to 9237 pages (~36 MB), far below vm.v_free_min=5055's neighborhood) while a malicious target blasted a 30 s stream of 48-byte NOP-IN PDUs into the kernel receiver (mtarget2463 + idrv2463). No panic. Because the receiver recycles each pdu via the freepdu list, pdu_alloc(M_NOWAIT) always found a free pdu and the objcache failure path was never hit. Exhausting the freepdu list would require a contrived workload that holds thousands of pdus outstanding simultaneously (e.g. many concurrent sessions with commands the target never completes) and simultaneous memory pressure — a real but impractical-to-engineer condition for a single-PoC guest run.

This is therefore an honest inconclusive: the deref is real and unconditional in the source, but the failure precondition (double M_NOWAIT failure while a PDU is in flight) does not manifest on this guest under the strongest pressure I could apply.

Threat model / severity

• Latent kernel NULL-deref panic. The realistic trigger is an attacker who can both (a) exhaust the per-session pdu pool and (b) induce system memory pressure, then drive the receiver. iSCSI is commonly used for root/boot volumes, so a panic here can wedge a box whose root is on iSCSI. Severity Medium is appropriate (latent DoS, hard to trigger).

PoC changes

• memhog.c (new): aggressive unprivileged memory-pressure driver (allocates+touches memory until malloc fails, then churns the resident set).
• mtarget2463.c (new): malicious target that accepts one connection and blasts a continuous stream of 48-byte NOP-IN PDUs (each forces so_input → pdu_alloc).
• idrv2463.c (new, from DF-2459's idrv.c): starts the kernel receiver (ISCSISETSES+ISCSISETSOC) without login and keeps it running for 30 s.
• build.sh / run.sh: build all three; run swap-off → memhog → wait for v_free_count < 12000 → mtarget+idrv.

Fix (fix.diff)

Add a NULL check after the retry so a double failure drops the PDU and returns ENOBUFS instead of dereferencing NULL (minimal, targeted at the unconditional deref; honours the author's deadlock concern by not switching to M_WAITOK):

  if(pq == NULL) {
       xdebug("pdu_alloc failed in so_input, dropping PDU");
       return ENOBUFS;
  }

Supersedes the finding markdown's framing: the finding suggested switching the retry to M_WAITOK; this fix instead keeps M_NOWAIT (avoiding the author's deadlock worry) and adds the missing NULL guard, which is the defensive minimum.

Fix validation

Status: not_testable (the live trigger is impractical on this guest, so a before/after panic comparison cannot be run). Validated that fix.diff applies cleanly to sys/dev/disk/iscsi/initiator/isc_soc.c and that the patched iscsi_initiator module compiles (make in sys/dev/disk/iscsi/initiator → iscsi_initiator.ko, MAKE_RC=0, no warnings under -Werror). The change is a 4-line NULL check; it cannot change behaviour on the unpatched path and only prevents the deref on the failure path.