[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thorsten Glaser
Subject: [Lynx-dev] [PATCH] Fix segfault in NSL_FORK child
Date: Thu, 30 Aug 2012 20:07:33 +0000 (UTC)


Index: WWW/Library/Implementation/HTTCP.c
RCS file: /cvs/src/gnu/usr.bin/lynx/WWW/Library/Implementation/HTTCP.c,v
retrieving revision
diff -u -p -r1.1.109.12 HTTCP.c
--- WWW/Library/Implementation/HTTCP.c  23 Aug 2012 17:48:06 -0000
+++ 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);
        } 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  CNAME    CNAME A A A A A A A A A
address@hidden:~ $ host -t aaaa  CNAME    CNAME AAAA    2A02:26F0:5:0:0:0:5F64:F96B 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 ;-)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]