Re: busybox: awk next_token(): heap-buffer-overflow (2nd OOB read in the same function; related to CVE-2023-42366; confirmed in all releases since 1.36.0)

Good catch!

Fixed in git, please try.

I don't think this is a security bug.
Most of the time, the malformed program which has unterminated
"string\<newline><NUL>
will just still be malformed even after trying to interpret bytes past
NUL as a program.

If it does happen to have a _valid_ continuation there, it will just
execute as if
this valid program was specified by the user.


On Thu, Aug 20, 2026 at 4:15 AM Ediz Yiğit via busybox
<[email protected]> wrote:
>
> Hello,
>
> we found a 1-byte heap out-of-bounds read in awk's tokenizer, editors/awk.c
> next_token() at line ~1207. The trigger differs from the previously reported
> CVE-2023-42366 (next_token, awk.c:1159 in 1.36.1), but it is the same bug class
> (out-of-bounds read while scanning a string token) in the same function.
>
> Affected versions (all verified from clean source with a proper ASan build):
> master (7473045ad) and release tags 1.36.0, 1.36.1, 1.37.0, 1.38.0. 1.35.0 was
> rebuilt and tested with the same protocol: it contains the same
> tokenizer code but
> the tested triggers did not reproduce the crash, so 1.36.0 is the oldest release
> we claim as affected.
>
> Root cause: in nextchar() (editors/awk.c), an unrecognized \z escape whose z is
> newline is "eaten" by advancing and retrying (goto again). When the awk program
> ends with \<newline> right after a string token, that retry reads the
> terminating
> NUL appended to the program buffer and advances one byte past it; the
> string-scan
> loop in next_token() then dereferences that byte:
>
>     while (*p != '"') {          /* OOB read: p one byte past buffer end */
>         if (*p == '\0' || *p == '\n')
>             syntax_error(EMSG_UNEXP_EOS);
>         ...
>     }
>
> Trigger (program file, 32 bytes, trailing backslash on last line):
>
>     BEGIN { print "ht "hi"  "hi" }\
>     (newline)
>
> ASan report (deterministic):
>
>     ERROR: AddressSanitizer: heap-buffer-overflow
>     READ of size 1 ... located 0 bytes after 33-byte region
>     #0 next_token editors/awk.c:1207:11
>
> Impact: Low on stock glibc builds (read hits padding; only a benign
> syntax error is
> emitted); DoS on ASan/instrumented builds. No write primitive. Build
> note: BusyBox
> only honors ASan via .config CONFIG_EXTRA_CFLAGS="-fsanitize=address", not via a
> CFLAGS_EXTRA make variable. Verification: every listed version was
> rebuilt from a
> fresh clean worktree with ASan enabled, and ASan presence was
> confirmed per build
> (nm); all five crash on the identical input at the same code path.
>
> A verified fix is included: do not advance past a NUL in nextchar() (stop and
> return it). Rebuilt with ASan: the trigger now fails cleanly with
> "Unexpected end
> of string"; the BusyBox awk testsuite shows no new failures (the same 3
> pre-existing ASan-build failures occur with and without the fix). Full patch:
> 0001-awk-fix-heap-oob.patch.
>
> Discovered with AFL++ (LLVM mode, clang-16, ASan build) targeting
> busybox awk -f.
>
> Given this is a second OOB read in the same function previously tracked as
> CVE-2023-42366, we would like to request a CVE for this finding, or, if it is
> already tracked, please let us know the reference. Happy to provide the exact
> trigger and verification data on request.
>
> PoC and full details: attachment disclosure-awk-next_token-heap-oob.md.
>
> Best regards
>
> Ediz Yiğit
> [email protected]
> _______________________________________________
> busybox mailing list
> [email protected]
> https://lists.busybox.net/mailman/listinfo/busybox
_______________________________________________
busybox mailing list
[email protected]
https://lists.busybox.net/mailman/listinfo/busybox