> Unfortunately I'm not an Emacs user and don't have time to dig into
> this. If there is anything to do from the w3m side please make sure keep
> me Cc'ed.
It is definitely a problem in w3m, not directly OpenBSD related. It's
another instance of https://todo.sr.ht/~rkta/w3m/59
As mentioned by Jeremie and Stuart, the problem involves w3m -dump_source
and w3m -dump_extra because the proc function pointer is used with
uninitialized garbage and we end up calling loadSomething with it:
(gdb) bt
#0 0x000000000000000e in ?? ()
#1 0x0000024048a684db in loadSomething (f=<optimized out>, loadproc=0xe, defaultbuf=0x242bb155d80) at file.c:230
#2 loadGeneralFile (path=0x242bb14e630 "lobste.rs", current=0x0, referer=0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>, flag=0, request=0x0) at file.c:2244
#3 0x0000024048a52cf2 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1033
The workaround I committed is to initialize it to NULL:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/w3m/patches/patch-file_c?annotate=1.8
On Fedora 41 the problem is hidden if w3m is compiled normally, but
if I compile it with clang and -fsanitize=address in LDFLAGS, CFLAGS and
CXXFLAGS, I get a deadly signal due to a wild jump (using the proc
variable uninitialized). This goes away and only leaks remain when I
apply the workaround.
$ ./w3m -dump_source https://lobste.rs
AddressSanitizer:DEADLYSIGNAL
=================================================================
==130007==ERROR: AddressSanitizer: SEGV on unknown address 0x7f162f14c8e1 (pc 0x7f162f14c8e1 bp 0x7ffec6b65af0 sp 0x7ffec6b659c8 T0)
==130007==The signal is caused by a READ memory access.
==130007==Hint: PC is at a non-executable region. Maybe a wild jump?
#0 0x7f162f14c8e1 (<unknown module>)
#1 0x00000053078f (/tmp/w3m/w3m+0x53078f) (BuildId: 0cbd1261085bc457d5bdd05ef83276c9bb4419b4)
#2 0x0000004e74ac (/tmp/w3m/w3m+0x4e74ac) (BuildId: 0cbd1261085bc457d5bdd05ef83276c9bb4419b4)
#3 0x7f162f810247 (/lib64/libc.so.6+0x3247) (BuildId: 515c33a35f41020661fea8ac4eb995e26ccd6b00)
#4 0x7f162f81030a (/lib64/libc.so.6+0x330a) (BuildId: 515c33a35f41020661fea8ac4eb995e26ccd6b00)
#5 0x000000401b74 (/tmp/w3m/w3m+0x401b74) (BuildId: 0cbd1261085bc457d5bdd05ef83276c9bb4419b4)
==130007==Register values:
rax = 0x00007f162f14c8e1 rbx = 0x00007f162f14db60 rcx = 0x00007f162f14f000 rdx = 0x00007f162f154e00
rdi = 0x00007ffec6b66040 rsi = 0x00007f162f154e00 rbp = 0x00007ffec6b65af0 rsp = 0x00007ffec6b659c8
r8 = 0x00000000000f86d0 r9 = 0x0000000000000000 r10 = 0x00000000000f86d2 r11 = 0x0000000000000001
r12 = 0x0000000000000003 r13 = 0x0000000000000000 r14 = 0x00007f16302e4000 r15 = 0x00000000007a15a0
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (<unknown module>)
==130007==ABORTING
No comments:
Post a Comment