Bug 77934
| Summary: | "ping6 -s 65528 ::1" results in a kernel-panic | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Gerd Rausch <gerd> | ||||
| Component: | kern | Assignee: | Hajimu UMEMOTO <ume> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | Unspecified | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
State Changed From-To: open->closed Duplicate of misc/77933. State Changed From-To: closed->open As bde pointed out misc/77934 has more details than misc/77933. Responsible Changed From-To: freebsd-bugs->ume Assign to our IPv6 guru. State Changed From-To: open->closed Yes, I think #1) alone shouldn't cause kernel-panic. I've just committed. Since #1) was fixed in KAME repo., I merged it from KAME. Thank you! |
root@propecia% ping6 -s 65528 ::1 PING6(65576=40+8p+65528 bytes) ::a1 --> ::1 nic: sbappendaddr panic(c0528560,c0528560,c04945b8,e1e77b50,4) at panic+0x9d panic(c04945b8,0,0,1000000,0) at panic+0x9d sbappendaddr(deecad4c,e1e77bbc,c1bbf300,c1bbf300,c1bbf300,28,c1bbf3d0,c1bbf300) at sbappendaddr+0x2e icmp6_rip6_input(e1e77c34,28,4d8,14,c1bbf300) at icmp6_rip6_input+0x247 icmp6_input(e1e77c98,e1e77d1c,3a,c1bfc2d8,c1bfc200) at icmp6_input+0x675 process_ipv6_headers(e1e77d3c,e1e77d40,3a,e1e77d1c,0) at process_ipv6_headers+0x17e ip6_input(c69a9c00,c1bbf300,1,c0307403) at ip6_input+0x229 ip6intr(c04538ea,0,c0469c1e,deecad00,0) at ip6intr+0xb8 swi_net_next(deecad00,c68e2960,e1e77e28,c1c1ae00,0) at swi_net_next sendit(e1d8fd40,3,e1e77eb8,0,806b3a0) at sendit+0x257 sendmsg(e1d8fd40,e1e77f68,c,c04609f4,e1e1f700) at sendmsg+0x98 syscall2(2f,2f,2f,bfbff6c0,10000) at syscall2+0x243 Xint0x80_syscall() at Xint0x80_syscall+0x25 Debugger("panic") Stopped at Debugger+0x55: movl $0xffffffff,0(%esp) db> Fix: The panic unveils two problems: #1) ip6_output calls ip6_process_hopopts with two uninitialized variables "dummy1" & "dummy2". Unfortunately, ip6_process_hopopts checks "dummy2" of a non-zero value and regards that as an error, triggering a "icmp6_error" to be sent. But that alone should not result in a kernel-panic, right? #2) icmp6_notify_error uses IP6_EXTHDR_CHECK, which in turn calls m_pullup. Now (un)fortunately, m_pullup returns the new mbuf that is contiguous. Unfortunately, icmp6_notify_error continues to use the old pointer, which after the m_pullup is not suitable as a packet header any longer (see m_move_pkthdr). And this is what causes the kernel panic in sbappendaddr later on. Here's a fix: How-To-Repeat: ping6 -s 65528 ::1