TrueNAS Enterprise

FreeBSD CTL HA, three independent pre-authentication remote kernel-code-execution primitives behind an unauthenticated failover port, and the project's answer is a manpage warning rather than a patch

Background. The CAM Target Layer is FreeBSD's in-kernel iSCSI and SCSI target subsystem; the code that makes a FreeBSD host present block storage to other machines. Its High-Availability mode exists so two controllers can act as one array, exchanging state and in-flight I/O over a private link, and the manpage documenting it carried a March 2017 date line until this disclosure changed it (FreeBSD Project, 2026-08-05). It is not enabled on a stock FreeBSD install (an administrator has to set kern.cam.ctl.ha_peer) but it is on by design wherever FreeBSD-derived storage appliances are deployed in a high-availability pair, which is where this matters for critical-infrastructure estates.

The design premise is stated plainly by the researcher: once HA is enabled, "the kernel listens on a TCP port (999 by default) for its peer, with no authentication. Whatever connects is trusted as the second controller." There is no key exchange, no handshake, and no peer validation to fall back on, which means every bug behind that port is reachable pre-authentication by anyone who can route a packet to it.

Three such bugs were reported in March and April 2026, and each is independently sufficient for kernel code execution. The first is an unchecked raw kernel pointer carried in HA data-channel messages: the receiving kernel dereferences a value the wire supplied, yielding arbitrary kernel read and write directly, and the GENERIC kernel ships without kernel address-space layout randomisation, so there is no address guessing to do. The second abuses a different untrusted wire pointer in the data-movement handler to obtain a write-only primitive, and uses it to repoint a handler function pointer, pivoting into the first bug's cleaner write path. The third is a heap overflow in the scatter-gather copy loop, where an unchecked entry count overflows a fixed 64-byte heap buffer into the adjacent allocator object; that one demands real exploitation work (grooming the slab, overwriting a callback pointer, pivoting the stack, and a return-oriented chain to clear the no-execute bit) rather than a single wire write.

What each chain finishes with is the operationally important part. Kernel shellcode creates a process and executes /bin/sh connected back to the attacker, and the receive thread is made to exit cleanly, so the machine stays up and serving storage. There is no crash, no panic, and no reboot; the absence of a failure signature is the point.

FreeBSD's response was not a code fix. The project's own commit, authored on 2026-08-04 and merged 2026-08-05, adds a warning to the ctl.4 manpage stating that "HA must be configured only on trusted networks: there is no authentication mechanism built in to the implementation, and the HA protocol effectively permits remote code execution on the peer node" (FreeBSD Project, 2026-08-05). The maintainers' stated position is that this is a private backchannel between two controllers that was never intended to face an untrusted network, so documentation is the appropriate remedy rather than bounds checks. That is a defensible engineering position and a difficult operational one: it means the exposure is permanent, the mitigation is entirely architectural, and working exploit scripts for all three primitives are published alongside the write-up. No CVE was assigned by either the project or the researchers, so a purely CVE-driven patch or scanning process will not surface this at all.

Detection, telemetry class first. Because every primitive executes in kernel context before any userland process exists, host-based endpoint telemetry has nothing to observe until the chain has already succeeded; the usable signal is network. In flow, connection or firewall telemetry, any session to the configured HA port from a source that is not the paired controller is definitionally illegitimate, since the protocol has no authentication that could make such a connection valid; a two-address allowlist on that port turns detection into a deny-log. After a successful chain, the connect-back is an ordinary outbound session, but its parent lineage is anomalous (a shell created from kernel context rather than descending from any expected service manager) which only kernel-level instrumentation will resolve. Triage: legitimate HA traffic on this port is continuous, bidirectional and between exactly two known addresses, so volume and content look unremarkable; the discriminator is purely the peer address, which is why an allowlist rather than a signature is the control that works.