panic: mbuf too short for IPv6 header

[Manuel Bouyer]

Hi,
on a recent -current (kernel sources as of yesterday), I've got several
panic: mbuf too short for IPv6 header

with the stack trace being:
0x0(0xf0c60500, 0x3a, 0x28, 0x169, 0xf2668dcc, 0x28) at netbsd:icmp6_input+0x78
icmp6_input(0xf0c60500, 0xf2668e70, 0x3a, 0xf2668e74, 0x6, 0x1) at netbsd:ip6_input+0x8ec
ip6_input(0x0, 0xe, 0x0, 0xf21474f0, 0x52e1474c, 0xf02ef580) at netbsd:ip6intr+0x68
ip6intr(0xf02ef400, 0xf2668edc, 0xf02ea400, 0x10, 0x44, 0x0) at netbsd:softint_thread+0x90
softint_thread(0xf212d170, 0xf2147980, 0xf02a8ac0, 0x0, 0x904010e1, 0x90401fe1) at netbsd:lwp_trampoline+0x8
End traceback...

I think it's related to running named on this box. Without named running,
the box had been up for several hours; with named the panic occurs in less
than one hour (tried 3 times).

Looking at the mail archives, it seems this issue has already been reported,
but I didn't find a definitive fix. The attached patch mimics code in
ipv4 icmp_input, and makes sure the related mbuf part is contigous and
writeable. With this patch, the box has been up for 13 hours with named
running, without problems. Does it look right ?

[Christos Zoulas]

-=-=-=-=-=-
Hi,
on a recent -current (kernel sources as of yesterday), I've got several
panic: mbuf too short for IPv6 header
0x0(0xf0c60500, 0x3a, 0x28, 0x169, 0xf2668dcc, 0x28) at netbsd:icmp6_input+0x78
icmp6_input(0xf0c60500, 0xf2668e70, 0x3a, 0xf2668e74, 0x6, 0x1) at netbsd:ip6_input+0x8ec
ip6_input(0x0, 0xe, 0x0, 0xf21474f0, 0x52e1474c, 0xf02ef580) at
netbsd:ip6intr+0x68
ip6intr(0xf02ef400, 0xf2668edc, 0xf02ea400, 0x10, 0x44, 0x0) at
netbsd:softint_thread+0x90
softint_thread(0xf212d170, 0xf2147980, 0xf02a8ac0, 0x0, 0x904010e1,
0x90401fe1) at netbsd:lwp_trampoline+0x8
End traceback...
I think it's related to running named on this box. Without named running,
the box had been up for several hours; with named the panic occurs in less
than one hour (tried 3 times).
Looking at the mail archives, it seems this issue has already been reported,
but I didn't find a definitive fix. The attached patch mimics code in
ipv4 icmp_input, and makes sure the related mbuf part is contigous and
writeable. With this patch, the box has been up for 13 hours with named
running, without problems. Does it look right ?

Looks good to me.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

+ i = off + sizeof(*icmp6);
+ if ((m->m_len < i || M_READONLY(m)) && (m = m_pullup(m, i)) == 0) {
+ ICMP6_STATINC(ICMP6_STAT_TOOSHORT);
+ icmp6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_error);
+ goto freeit;
+ }

You can write that more succinctly with M_UNWRITABLE().

Dave

[Steven M. Bellovin]

On Sun, 4 May 2008 13:00:29 +0200

Post by Manuel Bouyer
Hi,
on a recent -current (kernel sources as of yesterday), I've got
several panic: mbuf too short for IPv6 header
0x0(0xf0c60500, 0x3a, 0x28, 0x169, 0xf2668dcc, 0x28) at
netbsd:icmp6_input+0x78 icmp6_input(0xf0c60500, 0xf2668e70, 0x3a,
0xf2668e74, 0x6, 0x1) at netbsd:ip6_input+0x8ec ip6_input(0x0, 0xe,
0x0, 0xf21474f0, 0x52e1474c, 0xf02ef580) at netbsd:ip6intr+0x68
ip6intr(0xf02ef400, 0xf2668edc, 0xf02ea400, 0x10, 0x44, 0x0) at
netbsd:softint_thread+0x90 softint_thread(0xf212d170, 0xf2147980,
0xf02a8ac0, 0x0, 0x904010e1, 0x90401fe1) at netbsd:lwp_trampoline+0x8
End traceback...
I think it's related to running named on this box. Without named
running, the box had been up for several hours; with named the panic
occurs in less than one hour (tried 3 times).
Looking at the mail archives, it seems this issue has already been
reported, but I didn't find a definitive fix. The attached patch
mimics code in ipv4 icmp_input, and makes sure the related mbuf part
is contigous and writeable. With this patch, the box has been up for
13 hours with named running, without problems. Does it look right ?

Has this been committed? I just got that panic on what I think is
up-to-date source.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Steven M. Bellovin
On Sun, 4 May 2008 13:00:29 +0200

Post by Manuel Bouyer
Hi,
on a recent -current (kernel sources as of yesterday), I've got
several panic: mbuf too short for IPv6 header
0x0(0xf0c60500, 0x3a, 0x28, 0x169, 0xf2668dcc, 0x28) at
netbsd:icmp6_input+0x78 icmp6_input(0xf0c60500, 0xf2668e70, 0x3a,
0xf2668e74, 0x6, 0x1) at netbsd:ip6_input+0x8ec ip6_input(0x0, 0xe,
0x0, 0xf21474f0, 0x52e1474c, 0xf02ef580) at netbsd:ip6intr+0x68
ip6intr(0xf02ef400, 0xf2668edc, 0xf02ea400, 0x10, 0x44, 0x0) at
netbsd:softint_thread+0x90 softint_thread(0xf212d170, 0xf2147980,
0xf02a8ac0, 0x0, 0x904010e1, 0x90401fe1) at netbsd:lwp_trampoline+0x8
End traceback...
I think it's related to running named on this box. Without named
running, the box had been up for several hours; with named the panic
occurs in less than one hour (tried 3 times).
Looking at the mail archives, it seems this issue has already been
reported, but I didn't find a definitive fix. The attached patch
mimics code in ipv4 icmp_input, and makes sure the related mbuf part
is contigous and writeable. With this patch, the box has been up for
13 hours with named running, without problems. Does it look right ?

Has this been committed?

No, not yet.

[Manuel Bouyer]

Post by Manuel Bouyer
Hi,
on a recent -current (kernel sources as of yesterday), I've got several
panic: mbuf too short for IPv6 header
0x0(0xf0c60500, 0x3a, 0x28, 0x169, 0xf2668dcc, 0x28) at netbsd:icmp6_input+0x78
icmp6_input(0xf0c60500, 0xf2668e70, 0x3a, 0xf2668e74, 0x6, 0x1) at netbsd:ip6_input+0x8ec
ip6_input(0x0, 0xe, 0x0, 0xf21474f0, 0x52e1474c, 0xf02ef580) at netbsd:ip6intr+0x68
ip6intr(0xf02ef400, 0xf2668edc, 0xf02ea400, 0x10, 0x44, 0x0) at netbsd:softint_thread+0x90
softint_thread(0xf212d170, 0xf2147980, 0xf02a8ac0, 0x0, 0x904010e1, 0x90401fe1) at netbsd:lwp_trampoline+0x8
End traceback...
I think it's related to running named on this box. Without named running,
the box had been up for several hours; with named the panic occurs in less
than one hour (tried 3 times).
Looking at the mail archives, it seems this issue has already been reported,
but I didn't find a definitive fix. The attached patch mimics code in
ipv4 icmp_input, and makes sure the related mbuf part is contigous and
writeable. With this patch, the box has been up for 13 hours with named
running, without problems. Does it look right ?

FYI, I commited this patch. I've been running with it for 3 days, without
apparent problems.