Fix a stack-buffer-underflow in the "Did you know...?" tip-of-the-day dialog's tip-file parser.
CreateTipW() (app/bin/smalldlg.c) reads each line of the tips file and strips a trailing CR/LF:
cp = buff+strlen(buff)-1;
if (*cp=='\n') { cp--; }
if (*cp=='\r') { cp--; }
A blank line (just "\n", which is a normal separator between tips) has strlen 1, so
cp = buff+0 = buff. The first check sees '\n' and decrements to buff-1 -- one byte before the
buffer -- then the second check immediately dereferences that out-of-bounds pointer.
Confirmed as a genuine, deterministic bug (not just a theoretical edge case) via
AddressSanitizer: building the app with -fsanitize=address and simply starting it up (the tip
dialog shows on every launch by default) reliably reports:
ERROR: AddressSanitizer: stack-buffer-overflow ... READ of size 1 ...
#0 CreateTipW app/bin/smalldlg.c:104
Address ... is located in stack of thread T0 at offset 63 in frame
[64, 4160) 'buff' (line 71) <== Memory access at offset 63 underflows this variable
Found incidentally while investigating an unrelated crash report (SF #782 work) that required an
ASan-instrumented build; this bug fires on essentially every app startup once ASan is enabled,
before the app's own window even fully appears, so it had to be fixed first to get past it.
Fix: guard both decrements with a bounds check before dereferencing (cp >= buff) so a blank
line's cp never goes below buff. No functional change for any line that isn't blank.
Given the underflow is a fixed, small, constant offset (never more than one byte before a
4096+-byte stack buffer) and the tips file is a static, trusted, XTrkCAD-shipped resource (not
user-controlled/untrusted input), this has not been reported to be exploitable or to have caused
any user-visible symptom on its own -- it was only found because ASan flags every out-of-bounds
access regardless of real-world impact. Still worth fixing since it's cheap, correct, and removes
a genuine (if apparently harmless in practice) undefined-behavior instance.
Anonymous
Fixed as part of the #782 (Layer Groups) branch/PR -- found opportunistically while building an ASan-instrumented binary to investigate #785. git PR #181 merged (27/27 CI green), Hg branch pushed to SF. Holding out of Hg mainline for the normal review window alongside #782.
Correction: merged into Hg mainline (GTK3V2MAIN) separately from #782 via hg graft, not as part of that branch's merge -- #782 (Layer Groups) is being held back for further review while this fix lands on its own. Pushed to SF.