Hi, For the record, since trixie is marked "postponed (revisit when fixed upstream)":
Upstream issue #217 was closed on 2026-06-27 without a code change: https://www.google.com/url?q=https://github.com/netwide-assembler/nasm/issues/217&source=gmail&ust=1793766276822000&sa=E The reporter agreed in the thread that the maximum possible disasm() output is 247 bytes. That is less than the 256-byte outbuf that ndisasm passes in (disasm/ndisasm.c: char outbuf[256]; disasm(q, INSN_MAX, outbuf, sizeof(outbuf), ...)). So the "slen += snprintf(output + slen, outbufsize - slen, ...)" pattern never reaches truncation in the current code. The upstream maintainer (hpax) wrote: "I agree this should be cleaned up, but it is not a problem yet..." I tried to confirm this empirically on the Debian 3.01-1 source. I built ndisasm with -fsanitize=address and disassembled 20 MB of /dev/urandom in each mode: -b 16: 9842187 instructions, longest output line 84 chars, 0 ASan reports -b 32: 8197566 instructions, longest output line 92 chars, 0 ASan reports -b 64: 7950780 instructions, longest output line 99 chars, 0 ASan reports (Line length includes the address and hex-bytes columns, so the disasm() text itself is shorter still.) So there's no reachable overflow with the in-tree caller. The pattern would only matter for a hypothetical caller passing a smaller buffer. That probably makes this <unimportant> rather than something to wait on upstream for, but that's of course the security team's call. Thanks!
