DF-2458 — Target-controlled buffer offset in scsi_decap → arbitrary-offset kernel heap write

Verdict

REPRODUCED — a malicious iSCSI target obtains an attacker-controlled write-what-where primitive against the initiator kernel: the target's Data-In PDU supplies a 32-bit Buffer Offset (rcmd->bo) that scsi_decap() uses directly as dp = csio->data_ptr + ntohl(bo) and then memcpy()s the target's data segment to that address, with no bounds check. Demonstrated as a remote kernel panic (write to an unmapped page); the realistic ceiling is remote kernel memory corruption / RCE on a host that connects to a malicious target. Fix validated on a rebuilt module.

Mechanism (trigger → primitive → effect)

1. A privileged user runs iscontrol against the malicious target. The kernel receiver starts at ISCSISETSOC (iscsi.c:430), the login exchange completes (Security→Operational→FullFeature), CAM probes LUN 0, and the initiator issues a SCSI INQUIRY (a read, R=1, edtlen = alloc length). The outstanding command is placed on the held list (isc_sm.c:527-528).
2. The malicious target replies with a SCSI Data-In (opcode=0x25) whose itt matches the INQUIRY and whose Buffer Offset rcmd->bo is attacker-chosen (here 0x80000000).
3. ism_recv → _read_data (isc_sm.c:144) → i_search_hld finds the opq → scsi_decap (iscsi_subr.c:531). The only size guard is ntohl(cmd->edtlen) >= pq->pdu.ds_len (iscsi_subr.c:566) — it never checks placement: c offset = ntohl(rcmd->bo); /* iscsi_subr.c:572 -- target-controlled */ dp = csio->data_ptr + offset; /* iscsi_subr.c:573 -- NO bounds check */ i_mbufcopy(pq->mp, dp, len); /* iscsi_subr.c:574 -- memcpy to dp */
4. i_mbufcopy memcpy()s the target's data segment (attacker content, length ds_len) to csio->data_ptr + bo. With bo = 0x80000000 the destination is unmapped → write page-fault → panic. The offset is int, so values with the sign bit set (≥ 0x80000000) also yield underflow writes before the buffer.

Evidence (panic signature, unpatched #0)

With bo = 0x80000000 (and identically with bo = 0x40000000):

panic: assertion "obj != NULL" failed in vm_object_hold_shared at vm_object.c:330
vm_object_hold_shared()
vm_object_hold_shared()
vm_fault()
trap_pfault()
trap()
--- trap 000000000000000c, rip=ffffffff80bcabf6, rbp=... ---
memcpy() at memcpy+0x66

and (earlier run, bo = 0x40000000):

Fatal trap 12: page fault while in kernel mode
fault virtual address  = 0xfffff80157b32860
fault code             = supervisor write data, page not present     <-- WRITE fault
Stopped at      memcpy+0x66:    movq    %rdx,(%rdi)                  <-- i_mbufcopy

The supervisor write data fault inside memcpy (called by i_mbufcopy from scsi_decap) at an address = data_ptr + bo is the proof that the target's Buffer Offset is honored with no bounds check and that this is a write. Reproduced by mtarget2458 (login + malicious Data-In) + iscontrol (root, drives login→FFP→CAM INQUIRY). See panic.txt, mt2458.log.

Threat model / privilege boundary

• The attacker is the iSCSI target (malicious/compromised storage server). The victim is the kernel of any host whose iscsi_initiator connects to it. iSCSI needs no mutual auth by default (RFC 3720). The bug fires in normal full-feature operation (no special setup beyond connecting + a SCSI read probe, which CAM issues automatically on LUN discovery). The network→kernel boundary is crossed.
• Starting the session needs a privileged iscontrol (/dev/iscsi is 0600 root:wheel), which is the normal operational model.

Phase 6 — escalation analysis

This is a write-capable primitive (write-what-where relative to csio->data_ptr), so Phase 6 applies. What the attacker controls: - destination offset bo (full 32-bit, signed → underflow possible), - written content (the Data-In data segment bytes), - length ds_len (bounded by the negotiated MaxRecvDataSegmentLength).

What limits a clean uid=0 / RCE chain on this guest: - The destination is csio->data_ptr + bo — a relative write. To overwrite a specific kernel object (function pointer / struct ucred *) the attacker must know data_ptr's absolute heap address. KASLR is off, so kernel symbol addresses are fixed, but data_ptr is a dynamic heap allocation whose address is not known to a remote target without an info leak or successful heap grooming (the target can influence slab churn only indirectly, via the I/O it serves). The attacker is a network peer and has no local process on the victim, so the usual "spray/fork/pipe to fix the layout then pivot to userspace shellcode" local-escalation recipe is not directly applicable; RCE would require (a) a heap info-leak to pin data_ptr, then (b) a groomed adjacent victim object, then (c) redirecting a function pointer to shellcode staged in a kernel mbuf the attacker controls. - This is therefore reported at its demonstrated impact: remote kernel panic / DoS, with remote-kernel-RCE as the realistic (but not demonstrated in this PoC) ceiling. It is correctly rated Critical as a remote attacker-controlled kernel write primitive; the unpriv→uid=0 framing does not fit (there is no local unprivileged actor — the attacker is the network peer, the victim is the kernel).

PoC changes

• mtarget2458.c (new): malicious iSCSI target implementing the Login exchange (Security→Operational→FFP, permissive agreements) and replying to the first SCSI command with a Data-In carrying an attacker-chosen bo.
• fix.diff (new): bounds-check rcmd->bo in scsi_decap.

Fix (fix.diff)

In scsi_decap (iscsi_subr.c:572), before computing dp, require the placement to lie entirely inside the expected transfer buffer: offset >= 0 && offset + len <= edtlen; otherwise xdebug + drop the PDU (the command stays outstanding for a valid completion). Supersedes the finding markdown's proposal (which identified the unchecked rcmd->bo); this implements the exact bounds check at the faulting site.

A sibling instance of the same unchecked-bo pattern exists in so_recv's douio path (isc_soc.c:452, iov->iov_base = csio->data_ptr + ntohl(rcmd->bo)) which is reached only when sp->douio is enabled (default off); the same bounds check should be applied there. This fix targets the cited/reproduced scsi_decap path.

Fix validation (rebuilt single module)

• Baseline (unpatched #0): malicious Data-In bo=0x80000000 → panic: assertion obj!=NULL in vm_object_hold_shared via memcpy+0x66 (write fault) (panic.txt). Same with bo=0x40000000.
• Patched module (sha256 aadc9875...): same malicious Data-In → bounds check fires, guest stays up, dmesg: ">>> scsi_decap: 0] bad data-in offset=-2147483648 len=16 edtlen=36 - dropping". No panic, no da device (the malicious target never served valid data, as expected).