On Fri, Oct 15, 2021 at 08:39:16PM -0000, Stuart Henderson wrote:
> On 2021-10-15, Peter J. Philipp <p...@delphinusdns.org> wrote:
> > On Fri, Oct 15, 2021 at 08:05:08PM +0200, Otto Moerbeek wrote:
> > [ some cut ]
> >
> >> > Anything else I can collect.
> >>
> >> You might want to compile and install nsd wit debug symbols info:
> >>
> >> cd /usr/src/usr.sbin/nsd
> >> make -f Makefile.bsd-wrapper obj
> >> make -f Makefile.bsd-wrapper clean
> >> DEBUG=-g make -f Makefile.bsd-wrapper
> >> make -f Makefile.bsd-wrapper install
This will help a great deal...reason below.
> >>
> >> Then: collect a gdb trace from a running process: install gdb from ports,
> >> run
> >> egdb --pid=pidofnsdchild /usr/sbin/nsd
> >>
> >> and wait for the crash.
> >>
> >> But I'm mostly unfamiliar with the nsd code and what has been changed
> >> recently. I's say make sure sthen@ and florian@ see this: move to
> >> bugs@ as I do not know if they read misc@.
> >>
> >> -Otto
> >
> > Hi Otto and Mischa,
> >
> > I'm watching this unfold and I'm trying to convert this packet with tr and
> > sed but I'm having a hard time, getting this to 101 bytes. It would be cool
> > if you could show this packet in a hex dump ie. kdump -X or kdump -x.
> >
> > If you feel this really is a packet of nsd-death then I'd be interested in
> > seeing the hexdump privately. I know how to read some DNS formats but the
> > way it is in the kdump I'm having trouble converting that.
> >
> > Best Regards,
> > -peter
> >
> >> >
> >> > Mischa
> >> >
> >> >
> >> > >
> >> > > -Otto
> >> > >
> >> > > > 91127 nsd CALL
> >> > > > recvfrom(7,0xb2ac85b8000,0x20109,0,0xb2acfa96018,0xb27e485a968)
> >> > > > 91127 nsd GIO fd 7 read 101 bytes
> >> > > > "By\0\0\0\^A\0\0\0\0\0\^A\^A6\^A0\^A1\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A1\^A0\^A0\^A0\^A4\^A0\^A0\^A1\^A0\^A0\^A0\^A6\^A3\^A0\^Aa\^A2\^Cip6\^Darpa\0\0\f\0\
> >> > > > \^A\0\0)\^E\M-,\0\0\M^@\0\0\0"
> >> > > > 91127 nsd STRU struct sockaddr { AF_INET,
> >> > > > 141.101.75.185:10029 }
> >> > > > 91127 nsd RET recvfrom 101/0x65
> >> > > > 91127 nsd PSIG SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0x10
> >> > > > trapno=6
> >> > > > 36104 nsd STRU struct pollfd [2] { fd=16, events=0x1<POLLIN>,
> >> > > > revents=0<> } { fd=15, events=0x1<POLLIN>, revents=0<> }
> >> > > > 36104 nsd PSIG SIGCHLD caught handler=0xb27e47fa340 mask=0<>
> >>
> >
> >
>
> $ echo
> 'By\0\0\0\^A\0\0\0\0\0\^A\^A6\^A0\^A1\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A1\^A0\^A0\^A0\^A4\^A\^A\0\0)\^E\M-,\0\0\M^@\0\0\0'
> | unvis | hexdump -C
> 00000000 42 79 00 00 00 01 00 00 00 00 00 01 01 36 01 30 |By...........6.0|
> 00000010 01 31 01 30 01 30 01 30 01 30 01 30 01 30 01 30 |.1.0.0.0.0.0.0.0|
> 00000020 01 30 01 30 01 30 01 30 01 30 01 30 01 31 01 30 |.0.0.0.0.0.0.1.0|
> 00000030 01 30 01 30 01 34 01 01 00 00 29 05 ac 00 00 80 |.0.0.4....).....|
> 00000040 00 00 00 0a |....|
> 00000044
Thanks Stuart, unvis could be a life-saver. I have analysed this packet
visually and queried it against my own nameserver to get logging. It really
is fairly normal question packet, the edns0 OPT header is a bit weird in its
size 1452 bytes is what I got (05 ac) and the DO bit is set to on, which is
normal. In fact there was a lot of these packets in the kdump (about 10 of
them, I didn't check them all though but their size is identical) there was
1 TCP packet with a TCP payload of 103 bytes and DNS payload of 101 bytes,
so even here the packet seems to be fairly identical among all the childs
that died on sigsegv. They do differ in the DNS ID among those 10.
I did indulge a little in reading the edns code in nsd, but found no weaknesses
really.
I hope you guys can find more than what I did...
Best Regards,
-peter
>
> --
> Please keep replies on the mailing list.
>
