[Lynx-dev] [PATCH] Fix segfault in NSL_FORK child

[Thorsten Glaser]

Hi,

Index: WWW/Library/Implementation/HTTCP.c
===================================================================
RCS file: /cvs/src/gnu/usr.bin/lynx/WWW/Library/Implementation/HTTCP.c,v
retrieving revision 1.1.109.12
diff -u -p -r1.1.109.12 HTTCP.c
--- WWW/Library/Implementation/HTTCP.c  23 Aug 2012 17:48:06 -0000      
1.1.109.12
+++ WWW/Library/Implementation/HTTCP.c  30 Aug 2012 19:58:44 -0000
@@ -1480,7 +1480,7 @@ static size_t fill_addrinfo(char *buffer
        heap += phost->ai_addrlen;
 
        phost = phost->ai_next;
-       if (phost != 0) {
+       if (phost != 0 && (count + 1) < MAX_ADDRINFO) {
            actual->ai_next = (actual + 1);
            ++actual;
        } else {

is a “trivial” (i.e. only repeats the top-of-the-loop condition, this
can surely be expressed more nicely by a person who actually knows why
this particular code was written in this… particular… way) fix for a
problem I’ve been having that my kernel spews this:

Aug 30 19:53:26 blau /bsd: signal 11 received by (lynx:20711) UID(2999) 
EUID(2999), parent (lynx:22113) UID(2999) EUID(2999)
Aug 30 19:53:26 blau /bsd: core dumped for pid 20711 (lynx)

When I try to access a site with “many” RRs for their DNS name (way
too many, really: the recommendation was seven A RRs to not overload
the UDP packet):

address@hidden:~ $ host fbcdn-sphotos-d-a.akamaihd.net
fbcdn-sphotos-d-a.akamaihd.net  CNAME   
fbcdn-sphotos-d-a.akamaihd.net.edgesuite.net
fbcdn-sphotos-d-a.akamaihd.net.edgesuite.net    CNAME   a1404.dspw41.akamai.net
a1404.dspw41.akamai.net A       92.122.212.82
a1404.dspw41.akamai.net A       92.122.212.97
a1404.dspw41.akamai.net A       92.122.212.153
a1404.dspw41.akamai.net A       92.122.212.161
a1404.dspw41.akamai.net A       92.122.212.155
a1404.dspw41.akamai.net A       92.122.212.152
a1404.dspw41.akamai.net A       92.122.212.147
a1404.dspw41.akamai.net A       92.122.212.91
a1404.dspw41.akamai.net A       92.122.212.74
address@hidden:~ $ host -t aaaa fbcdn-sphotos-d-a.akamaihd.net
fbcdn-sphotos-d-a.akamaihd.net  CNAME   
fbcdn-sphotos-d-a.akamaihd.net.edgesuite.net
fbcdn-sphotos-d-a.akamaihd.net.edgesuite.net    CNAME   a1404.dspw41.akamai.net
a1404.dspw41.akamai.net AAAA    2A02:26F0:5:0:0:0:5F64:F96B
a1404.dspw41.akamai.net AAAA    2A02:26F0:5:0:0:0:5F64:F952

The issue was that actual->ai_next was prepared for the next
iteration of the loop, but there was no next iteration as the
exit condition of the while head was triggered, and thus any
code reading it (here, dump_addrinfo) read nōnsense, *then*
tried to follow that nōnsense’s ai_next field and went into
nirvana trying to follow *that* one’s.

So please apply this band-aid or re-do that loop (possibly
write ai_next only in the *next* iteration, or use a goto
instead of a while loop, or break…) properly.

I’m a bit scared of a comment near read_addrinfo() where
it says “repair pointers as done in fill_addrinfo”. Might
need looking at, too?

This is my first commit to MirBSD on the day after its tenth
birthday. (And actually, relatively late at night, after a
long workday made longer by not having quite recovered from
an illness.) Shows how much I love Lynx ;-)

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh