CVE-2026-90588

The HTTP client's debug helper print header field() in subsys/net/lib/http/http client.c formatted an http parser data-callback slice with a %s conversion: snprintk(output, len + 1, "%s", str). The parser hands its callbacks a pointer and a length into the caller's receive buffer, and those bytes are not NUL terminated. The size argument of snprintk() bounds only the destination, while the %s conversion measures the source first — lib/os/cbprintf complete.c uses strlen() when no precision is given, and lib/os/cbprintf nano.c uses strlen() unconditionally — so the read walks past the end of the header field and past the end of the receive buffer until it finds a zero byte.

The slice reaches the helper from on url(), on header field() and on header value(), which the parser invokes on bytes that http wait data() read straight off the socket into the application-supplied recv buf. A malicious or compromised HTTP server, or an attacker able to answer a plaintext request, therefore controls both the header field and the bytes that follow it in the buffer, and can guarantee that no zero byte appears before the buffer ends, forcing the over-read. The in-tree tests/net/lib/http client suite reproduces the over-read under CONFIG ASAN=y on an ordinary GET.

The impact is bounded. The whole helper body is compiled only when the HTTP client log module is explicitly set to Debug (CONFIG NET HTTP LOG LEVEL DBG=y, which the global CONFIG LOG DEFAULT LEVEL does not set), so default builds are unaffected. No out-of-bounds write occurs and none of the over-read bytes are emitted into the log, so there is no information disclosure; the consequence is an out-of-bounds read that can fault and panic the device where the buffer abuts an unmapped or MPU/MMU-protected region.

The fix copies exactly the len bytes the parser offered with memcpy() and terminates them, instead of relying on a %s conversion (a %.*s precision would not have sufficed, since cbprintf nano.c measures the source in full before applying it).