Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 Feb 2006 02:14:11 -0500
From:      Kris Kennaway <kris@obsecurity.org>
To:        "JINMEI Tatuya / ?$B?@L@C#:H" <jinmei@isl.rdc.toshiba.co.jp>
Cc:        net@FreeBSD.org, Kris Kennaway <kris@obsecurity.org>
Subject:   Re: Changing time causes ipv6 panics
Message-ID:  <20060211071411.GA82302@xor.obsecurity.org>
In-Reply-To: <y7vwtg2flhb.wl%jinmei@isl.rdc.toshiba.co.jp>
References:  <20060116004438.GA27901@xor.obsecurity.org> <20060207054502.GA18560@xor.obsecurity.org> <y7vhd7bjwye.wl%jinmei@isl.rdc.toshiba.co.jp> <20060211035025.GA77114@xor.obsecurity.org> <y7vwtg2flhb.wl%jinmei@isl.rdc.toshiba.co.jp>

next in thread | previous in thread | raw e-mail | index | archive | help

--IS0zKkzwUGydFO0o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 11, 2006 at 03:38:56PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> >>>>> On Fri, 10 Feb 2006 22:50:25 -0500,=20
> >>>>> Kris Kennaway <kris@obsecurity.org> said:
>=20
> >> Sorry, not really (we've not got a test environment to reproduce it).
> >> But from a quick review of nd6.c, there seems to be one thing that is
> >> obviously wrong.  The possible bug has been there since rev. 1.19
> >> committed in April 2002.  We've been probably just lucky so far...
> >>=20
> >> Could you try the patch attached below?  We'll probably also need to
> >> apply this fix to 4.X and 5.X.
>=20
> > The patch did not fix the panic.
>=20
> Hmm, but this time the point where the panic happened should be
> different.  Can you identify where it was?

I reduced the hw.physmem size and was able to get a dump:

Fatal trap 12: page fault while in kernel mode
cpuid =3D 0; apic id =3D 00
fault virtual address   =3D 0xffffffff80862198
fault code              =3D supervisor write, protection violation
instruction pointer     =3D 0x8:0xffffffff80333a86
stack pointer           =3D 0x10:0xffffffffabc31b50
frame pointer           =3D 0x10:0xffffffffabc31b80
code segment            =3D base 0x0, limit 0xfffff, type 0x1b
                        =3D DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        =3D interrupt enabled, resume, IOPL =3D 0
current process         =3D 14 (swi4: clock sio)
Dumping 3071 MB (2 chunks)
  chunk 0: 1MB (151 pages) ... ok
  chunk 1: 3071MB (786176 pages) 3056 3040 3024 3008 2992 2976 2960 2944 29=
28 2912 2896 2880 2864 2848 2832 2816 2800 2784 2768 2752 2736 2720 2704 26=
88 2672 2656 2640 2624 2608 2592 2576 2560 2544 2528 2512 2496 2480 2464 24=
48 2432 2416 2400 2384 2368 2352 2336 2320 2304 2288 2272 2256 2240 2224 22=
08 2192 2176 2160 2144 2128 2112 2096 2080 2064 2048 2032 2016 2000 1984 19=
68 1952 1936 1920 1904 1888 1872 1856 1840 1824 1808 1792 1776 1760 1744 17=
28 1712 1696 1680 1664 1648 1632 1616 1600 1584 1568 1552 1536 1520 1504 14=
88 1472 1456 1440 1424 1408 1392 1376 1360 1344 1328 1312 1296 1280 1264 12=
48 1232 1216 1200 1184 1168 1152 1136 1120 1104 1088 1072 1056 1040 1024 10=
08 992 976 960 944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 =
704 688 672 656 640 624 608 592 576 560 544 528 512 496 480 464 448 432 416=
 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 11=
2 96 80 64 48 32 16

#0  doadump () at pcpu.h:172
172     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:172
#1  0xffffffff80181f31 in db_fncall (dummy1=3D0, dummy2=3D0, dummy3=3D0, du=
mmy4=3D0x0) at ../../../ddb/db_command.c:489
#2  0xffffffff80181c80 in db_command (last_cmdp=3D0xffffffff805cfea8, cmd_t=
able=3D0x0, aux_cmd_tablep=3D0xffffffff8047ebd0,
    aux_cmd_tablep_end=3D0xffffffff8047ebd8) at ../../../ddb/db_command.c:4=
04
#3  0xffffffff80181da7 in db_command_loop () at ../../../ddb/db_command.c:4=
55
#4  0xffffffff80183feb in db_trap (type=3D-1413277552, code=3D0) at ../../.=
./ddb/db_main.c:221
#5  0xffffffff80280d0c in kdb_trap (type=3D12, code=3D0, tf=3D0xffffffffabc=
31aa0) at ../../../kern/subr_kdb.c:485
#6  0xffffffff803ea0ab in trap_fatal (frame=3D0xffffffffabc31aa0, eva=3D184=
46744071570858392)
    at ../../../amd64/amd64/trap.c:687
#7  0xffffffff803e9d1c in trap_pfault (frame=3D0xffffffffabc31aa0, usermode=
=3D0) at ../../../amd64/amd64/trap.c:609
#8  0xffffffff803e9915 in trap (frame=3D
      {tf_rdi =3D -2141607072, tf_rsi =3D -1096395428656, tf_rdx =3D 64, tf=
_rcx =3D 4, tf_r8 =3D 0, tf_r9 =3D 4, tf_rax =3D 80, tf_rbx =3D -2138693632=
, tf_rbp =3D -1413276800, tf_r10 =3D -1096385087968, tf_r11 =3D 14073748829=
6312, tf_r12 =3D 0, tf_r13 =3D -2138689536, tf_r14 =3D 0, tf_r15 =3D -21441=
26592, tf_trapno =3D 12, tf_addr =3D -2138693224, tf_flags =3D -27503810621=
59859712, tf_err =3D 3, tf_rip =3D -2144126330, tf_cs =3D 8, tf_rflags =3D =
66054, tf_rsp =3D -1413276832, tf_ss =3D 16})
    at ../../../amd64/amd64/trap.c:383
#9  0xffffffff803d46ab in calltrap () at ../../../amd64/amd64/exception.S:1=
68
#10 0xffffffff80333a86 in nd6_timer (ignored_arg=3D0xffffffff8059ab60) at .=
./../../netinet6/nd6.c:585
#11 0xffffffff80270bf9 in softclock (dummy=3D0xffffffff8059ab60) at ../../.=
./kern/kern_timeout.c:290
#12 0xffffffff802442a6 in ithread_execute_handlers (p=3D0xffffffff8059ab60,=
 ie=3D0xffffff000087b800)
    at ../../../kern/kern_intr.c:662
#13 0xffffffff80244423 in ithread_loop (arg=3D0xffffffff8059ab60) at ../../=
../kern/kern_intr.c:745
#14 0xffffffff80242c4a in fork_exit (callout=3D0xffffffff802443b0 <ithread_=
loop>, arg=3D0xffffff00000364e0,
    frame=3D0xffffffffabc31c90) at ../../../kern/kern_fork.c:802
#15 0xffffffff803d4a0e in fork_trampoline () at ../../../amd64/amd64/except=
ion.S:394
#16 0x0000000000000000 in ?? ()
Previous frame identical to this frame (corrupt stack?)
(kgdb) frame 10
#10 0xffffffff80333a86 in nd6_timer (ignored_arg=3D0xffffffff8059ab60) at .=
./../../netinet6/nd6.c:585
585                             ia6->ia6_flags |=3D IN6_IFF_DEPRECATED;

That's the same place it was before.  Note that this is a
use-after-free situation: memguard is monitoring the ifaddr malloc
type, and caused the panic when this code attempted to write into a
malloced structure after it had been freed.

Kris


--IS0zKkzwUGydFO0o
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFD7Y7DWry0BWjoQKURAvFoAKCiiZqOOIDWItF1a6QlxrnF4qgduwCfTHIq
pzMIf9M79InkWMFm1iHYykY=
=ZJJx
-----END PGP SIGNATURE-----

--IS0zKkzwUGydFO0o--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060211071411.GA82302>