[Lynx-dev] SIGSEGV in scan_cookie_sublist

[Thorsten Glaser]

Hi,

I just got one of these:

「A Fatal error has occurred in Lynx Ver. 2.8.8dev.15-MirOS-0AB2.1

Please notify your system administrator to confirm a bug, and
if confirmed, to notify the lynx-dev list.  Bug reports should
have concise descriptions of the command and/or URL which causes
the problem, the operating system name with version number, the
TCPIP implementation, and any other relevant information.

Do NOT mail the core file if one was generated.

Lynx now exiting with signal:  11

Abort trap (core dumped)」

Obviously the core dump file is of not much use, since Lynx
insists on installing its own SIGSEGV handler to produce said
message, but by manually inspecting the stack beyond the frame
of the FatalProblem function I found the last address in the
code segment belonged to scan_cookie_sublist+80:

Dump of assembler code for function scan_cookie_sublist:
0x1c076f90 <scan_cookie_sublist+0>:     push   ebp
0x1c076f91 <scan_cookie_sublist+1>:     mov    ebp,esp
0x1c076f93 <scan_cookie_sublist+3>:     push   edi
0x1c076f94 <scan_cookie_sublist+4>:     push   esi
0x1c076f95 <scan_cookie_sublist+5>:     push   ebx
0x1c076f96 <scan_cookie_sublist+6>:     sub    esp,0x2c
0x1c076f99 <scan_cookie_sublist+9>:     mov    eax,ds:0x3c060160
0x1c076f9e <scan_cookie_sublist+14>:    mov    DWORD PTR [ebp-28],eax
0x1c076fa1 <scan_cookie_sublist+17>:    mov    edi,DWORD PTR [ebp+8]
0x1c076fa4 <scan_cookie_sublist+20>:    mov    eax,DWORD PTR [ebp+12]
0x1c076fa7 <scan_cookie_sublist+23>:    mov    DWORD PTR [ebp-52],eax
0x1c076faa <scan_cookie_sublist+26>:    mov    eax,DWORD PTR [ebp+20]
0x1c076fad <scan_cookie_sublist+29>:    mov    DWORD PTR [ebp-56],eax
0x1c076fb0 <scan_cookie_sublist+32>:    push   0x0
0x1c076fb2 <scan_cookie_sublist+34>:    call   0x1c003944 <init_fallthru+2544>
0x1c076fb7 <scan_cookie_sublist+39>:    mov    DWORD PTR [ebp-44],eax
0x1c076fba <scan_cookie_sublist+42>:    mov    DWORD PTR [ebp-40],edx
0x1c076fbd <scan_cookie_sublist+45>:    push   0x9
0x1c076fbf <scan_cookie_sublist+47>:    push   0xa
0x1c076fc1 <scan_cookie_sublist+49>:    push   0xd
0x1c076fc3 <scan_cookie_sublist+51>:    push   0x3c040a0b
0x1c076fc8 <scan_cookie_sublist+56>:    lea    eax,[ebp-36]
0x1c076fcb <scan_cookie_sublist+59>:    push   eax
0x1c076fcc <scan_cookie_sublist+60>:    call   0x1c003a24 <init_fallthru+2768>
0x1c076fd1 <scan_cookie_sublist+65>:    mov    esi,DWORD PTR [ebp-56]
0x1c076fd4 <scan_cookie_sublist+68>:    add    esp,0x18
0x1c076fd7 <scan_cookie_sublist+71>:    test   esi,esi
0x1c076fd9 <scan_cookie_sublist+73>:    je     0x1c0772db 
<scan_cookie_sublist+843>
0x1c076fdf <scan_cookie_sublist+79>:    nop
0x1c076fe0 <scan_cookie_sublist+80>:    mov    ebx,DWORD PTR [esi]
0x1c076fe2 <scan_cookie_sublist+82>:    test   ebx,ebx
0x1c076fe4 <scan_cookie_sublist+84>:    je     0x1c0772d0 
<scan_cookie_sublist+832>
[…]

The call in scan_cookie_sublist+60 appears to be sprintf from:

(gdb) list scan_cookie_sublist
713                                      char *path,
714                                      int port,
715                                      HTList *sublist,
716                                      char *header,
717                                      int secure)
718     {
719         HTList *hl;
720         cookie *co;
721         time_t now = time(NULL);
722         char crlftab[8];
(gdb)
723
724         sprintf(crlftab, "%c%c%c", CR, LF, '\t');
725         for (hl = sublist; hl != NULL; hl = hl->next) {
726             co = (cookie *) hl->object;
727
728             if (co == NULL) {
729                 continue;
730             }
731
732             /* speed-up host_matches() and limit trace output */

Then, scan_cookie_sublist+71 is the “hl != NULL” comparison
from the for, and the faulting instruction at +80 is the
dereference “hl->object” (since the “object” member of the
HTList is at offset 0).

This basically means that it’s possible, during normal Lynx
operation, for “sublist” to contain a faulty but non-NULL hl
entry.

Due to the signal handler, I cannot inspect the context
at that point to indicate the precise value. But you might
want to take this as a heads-up for investigation.

bye,
//mirabilos
-- 
[DJBDNS Zone] TTL 86400 – <Natureshadow> kann man da auch 1d schreiben?
<mirabilos> nö, außerdem kann ein Deutscher oder ein Japaner mit 1d
    ja erstmal nix anfangen, oder könntest du 1日 im zone file lesen?
<Natureshadow> das heißt für mich: ein Regal, das u.U. schiefstehen könnte