On Tue, Feb 07, 2006 at 07:16:09PM +0900, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote: > >>>>> On Tue, 7 Feb 2006 00:45:02 -0500, > >>>>> Kris Kennaway <[EMAIL PROTECTED]> said: > > >> 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): > > > Has anyone looked at this? This is on the TODO list for 6.1, so the > > sooner it can be resolved the better. > > 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... > > 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 = 0; apic id = 00
fault virtual address = 0xffffffff919d5198
fault code = supervisor write, protection violation
instruction pointer = 0x8:0xffffffff8031fa76
stack pointer = 0x10:0xffffffffbcda4b60
frame pointer = 0x10:0xffffffffbcda4b90
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 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 = 0, rsp = 0xffffffffbcda4d40, rbp = 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
pgp0WFrCjiFTx.pgp
Description: PGP signature
