Bug 189895
| Summary: | NULL pointer derefrence panic from icmpv6_send | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Doug Chapman <dchapman> |
| Component: | kernel | Assignee: | Thomas Graf <tgraf> |
| Status: | CLOSED CANTFIX | QA Contact: | Brian Brock <bbrock> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 4.0 | CC: | jbaron, rkhan |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-11-03 12:53:58 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
FYI, was able to reproduce on x86_64 so I am setting hardware to "all". Is this bug still occurring? I'm closing this bugzilla as there was no answer to my ping. Feel free to reopen the bug if the problem still occurs. |
Description of problem: The following panic is seen on my ia64 systems when running the network portion of the LTP test suite. I have narrowed this down and have an easy reproducer that does not rely on LTP. Unable to handle kernel NULL pointer dereference (address 0000000000000160) ping6[3558]: Oops 11012296146944 [1] Modules linked in: scsi_dump diskdump ah6 deflate zlib_deflate twofish serpent aes blowfish des sha256 crypto_null af_key md5 ipv6 parport_pc lp parport autofs4 sunrpc ds yenta_socket pcmcia_core vfat fat button ohci_hcd ehci_hcd e1000 dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod qla2300 qla2xxx lpfc scsi_transport_fc mptscsih mptsas mptspi mptfc mptscsi mptbase sd_mod scsi_mod Pid: 3558, CPU 0, comm: ping6 psr : 0000121008126010 ifs : 8000000000000b1e ip : [<a0000002006dad91>] Not tainted ip is at icmpv6_send+0x8d1/0x1080 [ipv6] unat: 0000000000000000 pfs : 0000000000000b1e rsc : 0000000000000003 rnat: 0000000000000000 bsps: 0000000000000000 pr : 65952aa5a5a55559 ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c0270033f csd : 0000000000000000 ssd : 0000000000000000 b0 : a0000002006dad80 b6 : a00000010056a960 b7 : a0000001005434e0 f6 : 0ffff8000000000000000 f7 : 1003e20c49ba5e353f7cf f8 : 1003e0000000000dd1382 f9 : 1003effffffffffff0000 f10 : 1003e0000000000000001 f11 : 0ffeefffffffff0000000 r1 : a000000200894000 r2 : 0000000000000100 r3 : 0000000000000200 r8 : 0000000000002740 r9 : 0000000000000100 r10 : 00000000000000fd r11 : 00000000000000ff r12 : e00000407dae7a50 r13 : e00000407dae0000 r14 : 0000000000000000 r15 : e0000040409a2858 r16 : 0000000000000010 r17 : a000000200734160 r18 : e000000001010000 r19 : e00000407df372e0 r20 : e00000407df372d0 r21 : e00000407dae7ac0 r22 : e00000407df3728a r23 : 0000000000000000 r24 : e00000407dae79c0 r25 : e00000407dae79c8 r26 : 0000000000000000 r27 : 0000000000000024 r28 : e000000001008a00 r29 : 0000000000000000 r30 : 0000000000000000 r31 : e00000407df372c0 Call Trace: [<a000000100016d00>] show_stack+0x80/0xa0 sp=e00000407dae75e0 bsp=e00000407dae1540 [<a000000100017610>] show_regs+0x890/0x8c0 sp=e00000407dae77b0 bsp=e00000407dae14f8 [<a00000010003e7f0>] die+0x150/0x240 sp=e00000407dae77d0 bsp=e00000407dae14b8 [<a000000100063f00>] ia64_do_page_fault+0x8c0/0xbc0 sp=e00000407dae77d0 bsp=e00000407dae1450 [<a00000010000f560>] ia64_leave_kernel+0x0/0x260 sp=e00000407dae7880 bsp=e00000407dae1450 [<a0000002006dad90>] icmpv6_send+0x8d0/0x1080 [ipv6] sp=e00000407dae7a50 bsp=e00000407dae1358 [<a000000200708260>] xfrm6_output+0x7c0/0x980 [ipv6] sp=e00000407dae7ae0 bsp=e00000407dae12e0 [<a0000002006a2140>] ip6_push_pending_frames+0x740/0xb60 [ipv6] sp=e00000407dae7af0 bsp=e00000407dae1258 [<a0000002006d8750>] rawv6_sendmsg+0x1950/0x1b20 [ipv6] sp=e00000407dae7b20 bsp=e00000407dae1168 [<a0000001005435b0>] inet_sendmsg+0xd0/0x100 sp=e00000407dae7be0 bsp=e00000407dae1130 [<a000000100477cd0>] sock_sendmsg+0x230/0x280 sp=e00000407dae7be0 bsp=e00000407dae1100 [<a00000010047b880>] sys_sendto+0x180/0x280 sp=e00000407dae7d50 bsp=e00000407dae1068 [<a00000010000f400>] ia64_ret_from_syscall+0x0/0x20 sp=e00000407dae7e30 bsp=e00000407dae1068 [<a000000000010640>] 0xa000000000010640 sp=e00000407dae8000 bsp=e00000407dae1068 Version-Release number of selected component (if applicable): kernel-2.6.9-34.22.EL How reproducible: Every time Steps to Reproduce: Requires 2 systems: On system A 1. ifconfig eth0 add fd00:1:1:1::2/64 2. setkey -F -P 3. echo 'add fd00:1:1:1::2 fd00:1:1:1::1 ah 1000 -m tunnel -A hmac-sha1 "beef_fish_pork_salad" ; add fd00:1:1:1::1 fd00:1:1:1::2 ah 1001 -m tunnel -A hmac-sha1 "beef_fish_pork_salad" ; spdadd fd00:1:1:1::2 fd00:1:1:1::1 any -P out ipsec ah/tunnel/fd00:1:1:1::2-fd00:1:1:1::1/use ; spdadd fd00:1:1:1::1 fd00:1:1:1::2 any -P in ipsec ah/tunnel/fd00:1:1:1::1-fd00:1:1:1::2/use ;' | setkey -c Then, on system B: 1. ifconfig eth0 add fd00:1:1:1::1/64 2. setkey -F -P 3. echo 'add fd00:1:1:1::2 fd00:1:1:1::1 ah 1000 -m tunnel -A hmac-sha1 "beef_fish_pork_salad" ; add fd00:1:1:1::1 fd00:1:1:1::2 ah 1001 -m tunnel -A hmac-sha1 "beef_fish_pork_salad" ; spdadd fd00:1:1:1::2 fd00:1:1:1::1 any -P in ipsec ah/tunnel/fd00:1:1:1::2-fd00:1:1:1::1/use ; spdadd fd00:1:1:1::1 fd00:1:1:1::2 any -P out ipsec ah/tunnel/fd00:1:1:1::1-fd00:1:1:1::2/use ;' | setkey -c 4. ping6 -I eth0 -c 1 fd00:1:1:1::2 -s 10000 system B will panic. Actual results: Panic! Expected results: No panic! Additional info: