I filed an issue upstream: https://github.com/KJ7LNW/nec2c/issues/2
-ch On Fri, Aug 14, 2026 at 2:25 AM Hibby <[email protected]> wrote: > Thanks, I'll get on this later! > > -- > Dave Hibberd <[email protected]> > Debian Developer > Packet Radioist > MM0RFN > > On Tue, 11 Aug 2026, at 11:04 PM, ch wrote: > > Package: nec2c > > Version: 1.3.1-3 > > Severity: important > > Tags: upstream security > > > > main() reads deck lines into an 81-byte buffer, while load_line() fills a > > caller's buffer with up to LINE_LEN (132) characters plus a terminator: > > > > main.c:41 char ain[3], line_buf[81]; > > nec2c.h:81 #define LINE_LEN 132 > > misc.c while( num_chr < LINE_LEN ) { buff[num_chr++] = (char)chr; > ... } > > buff[num_chr] = '\0'; > > > > A card line longer than 81 characters therefore overflows line_buf by up > to 52 > > bytes. A NEC-2 comment card is 80 columns plus its "CM ", so ordinary > input > > reaches it; no malformed or hostile deck is required. > > > > Reproducer -- a deck whose second CM card is 100 characters. It must not > be > > the first line, which is read on a different path: > > > > { > > echo "CM first" > > echo "CM $(printf 'A%.0s' {1..100})" > > echo "CE" > > echo "GW 1 9 0 0 0 0 0 1 0.001" > > echo "GE 0" > > echo "EK" > > echo "EX 0 1 5 0 1.0 0.0" > > echo "FR 0 1 0 0 145.9 0" > > echo "RP 0 3 1 1000 0 0 30 0" > > echo "EN" > > } > t.nec > > nec2c -i t.nec -o t.out > > > > Built from the 1.3.1-3 source with gcc -O0 -g -fsanitize=address: > > > > ERROR: AddressSanitizer: stack-buffer-overflow > > WRITE of size 1 > > #0 load_line misc.c:154 > > #1 main main.c:269 > > [1920, 2001) 'line_buf' (line 41) <== Memory access at offset 2001 > > overflows this variable > > > > The packaged binary usually does not crash, because main()'s infile[81] > and > > otfile[81] are adjacent to line_buf and absorb the overrun rather than > the > > stack canary. That makes it quiet, not harmless: it is an out-of-bounds > write > > whose length is controlled by the input file. > > > > Severity: this is a local command-line tool reading a file the user > chose, so > > I have not filed it as a security issue. It would deserve one for any > workflow > > that feeds it decks from an untrusted source. > > > > Upstream status: upstream git (https://github.com/KJ7LNW/nec2c) widened > the > > buffer to LINE_LEN in 3d8c230, before tagging v1.3.1. That reduces the > > overflow to a single byte but does not remove it -- load_line() still > writes > > buff[LINE_LEN] into a char[LINE_LEN] -- and I have reported that > separately. > > There is therefore no released upstream version to upgrade to yet. > > > > Suggested fix, which is sufficient on its own against the 1.3.1-3 source: > > > > --- a/main.c > > +++ b/main.c > > @@ > > - char ain[3], line_buf[81]; > > + char ain[3], line_buf[LINE_LEN+1]; > > > > With that applied, ASan is clean on the reproducer and an over-long line > is > > rejected rather than corrupting memory. >
