Hi Adam,
Thanks for the speedy response.
On Sunday 13 June 2021 at 17:25:20 +0200, Adam Lackorzynski wrote:
> Hi,
>
> thanks for the report. The issue has always been there and had to do
> with the width of minicom's window (over 256 columns). I have addressed
> this.
Aha. I switched font at a similar time to upgrading to Bullseye and hadn't
realised that this meant that my window was no so wide!
> Martin, I have pushed this on the 2.8.x branch (8deebed). Please
> pick both changes there for the next upload.
I tried compiling master (f118eb9efe89672e5c2a75b34960813db493b2ed) with
your fix and -fsanitize=address. It looks like the original problem no
longer occurs, but now when I follow the original steps I get:
=================================================================
==56567==ERROR: AddressSanitizer: global-buffer-overflow on address
0x557fff340c20 at pc 0x557fff2f550b bp 0x7ffe7d9321e0 sp 0x7ffe7d9321d8
READ of size 4 at 0x557fff340c20 thread T0
#0 0x557fff2f550a in mc_wdrawelm_var ../../src/window.c:1059
#1 0x557fff2d45dc in find_next ../../src/minicom.c:338
#2 0x557fff2d04c1 in scrollback ../../src/minicom.c:540
#3 0x557fff2d04c1 in main ../../src/minicom.c:1707
#4 0x7f88fb12cd09 in __libc_start_main ../csu/libc-start.c:308
#5 0x557fff2d3059 in _start
(/overflow/mac/nobackup/git/minicom/build/src/minicom+0x25059)
0x557fff340c20 is located 32 bytes to the left of global variable
'iconv_enabled' defined in '../../src/minicom.c:937:12' (0x557fff340c40) of
size 4
0x557fff340c20 is located 0 bytes to the right of global variable 'outofrange'
defined in '../../src/minicom.c:177:14' (0x557fff340420) of size 2048
SUMMARY: AddressSanitizer: global-buffer-overflow ../../src/window.c:1059 in
mc_wdrawelm_var
Shadow bytes around the buggy address:
0x0ab07fe60130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab07fe60140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab07fe60150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab07fe60160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab07fe60170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ab07fe60180: 00 00 00 00[f9]f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
0x0ab07fe60190: 00 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
0x0ab07fe601a0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
0x0ab07fe601b0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
0x0ab07fe601c0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
0x0ab07fe601d0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==56567==ABORTING
I hope this is meaningful to you. If not, I'll see if I can work out
anything more.
Thanks.
Mike.
