Date: Fri, 10 Feb 2006 22:50:25 -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: <20060211035025.GA77114@xor.obsecurity.org> In-Reply-To: <y7vhd7bjwye.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>
next in thread | previous in thread | raw e-mail | index | archive | help
--huq684BweRXVnRxX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Feb 07, 2006 at 07:16:09PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> >>>>> On Tue, 7 Feb 2006 00:45:02 -0500,=20
> >>>>> Kris Kennaway <kris@obsecurity.org> said:
>=20
> >> I ran ntpdate on an amd64 system with ipv6 enabled and a skewed clock
> >> (ntpdate stepped it back by about an hour), and immediately got a
> >> use-after-free panic in ifaddr. When I rebooted with memguard enabled
> >> on this malloc type and retried, I got this panic upon changing the
> >> date forward, then back, then forward again (also note the garbage
> >> return data from ntpdate):
>=20
> > Has anyone looked at this? This is on the TODO list for 6.1, so the
> > sooner it can be resolved the better.
>=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.
The patch did not fix the panic.
Fatal trap 12: page fault while in kernel mode
cpuid =3D 0; apic id =3D 00
fault virtual address =3D 0xffffffff919d5198
fault code =3D supervisor write, protection violation
instruction pointer =3D 0x8:0xffffffff8031fa76
stack pointer =3D 0x10:0xffffffffbcda4b60
frame pointer =3D 0x10:0xffffffffbcda4b90
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)
[thread pid 14 tid 100010 ]
Stopped at nd6_timer+0x106: movl %eax,0x198(%rbx)
db> wh
Tracing pid 14 tid 100010 td 0xffffff03e15d6c30
nd6_timer() at nd6_timer+0x106
softclock() at softclock+0x279
ithread_execute_handlers() at ithread_execute_handlers+0x12f
ithread_loop() at ithread_loop+0x99
fork_exit() at fork_exit+0xdf
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip =3D 0, rsp =3D 0xffffffffbcda4d40, rbp =3D 0 ---
db>
> (a note about the patch: the first chunk is actually not related to
> the bug, but I could not miss the trivial typo)
You missed the other one though :-)
> - * However, from a stricter speci-confrmance standpoint, we should
> + * However, from a stricter spec-confrmance standpoint, we should
^o
Kris
--huq684BweRXVnRxX
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
iD8DBQFD7V8BWry0BWjoQKURAre3AKD3OcY47WraUlT1cO8IWihXA9Px1gCg2686
pc4yt9EYr/UQYfxSczsPkVI=
=72Zw
-----END PGP SIGNATURE-----
--huq684BweRXVnRxX--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060211035025.GA77114>