Hi, I m working on linux-3.12.19 kernel. In our board, we have an IPsec tunnel which carries IPv6 traffic inside Packet structure looks like below, IPv4(OuterIP) || ESP || IPv6(Inner IP) || IPv6 Frag HDR || UDP || Payload. I have written an application which constructs Inner IPv6 packets and writes to raw socket. Through application I m generating IPv6 packets of length not more than 1340. If length of the IPv6 packet is more than 1340, application does the IPv6 fragmentation and 2 fragments are written to raw socket. If I run this application using a script continously, there is no issue observed for around 30-40 mins. After that we see kernel panic with the stack trace like below. Unable to handle kernel paging request for data at address 0x000004d0 Faulting instruction address: 0xc000000000789578 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=24 CoreNet Generic Modules linked in: shm(O) l1d(O) hetmgr(O) sl_reset(O) cu_led(O) airv1588(O) CPU: 7 PID: 2512 Comm: pdcpUlSockTh Tainted: G W O 3.12.19-rt30 #1 task: c0000003fb42dc40 ti: c0000003ef9a0000 task.ti: c0000003ef9a0000 NIP: c000000000789578 LR: c00000000078ca48 CTR: c00000000078c8f0 REGS: c0000003ef9a2f10 TRAP: 0300 Tainted: G W O (3.12.19-rt30) MSR: 0000000080029000 <CE,EE,ME> CR: 24008422 XER: 20000000 SOFTE: 1 DEAR: 00000000000004d0, ESR: 0000000000000100 GPR00: c00000000078ca48 c0000003ef9a3190 c000000000d6b3a0 c0000003ef9a33a0 GPR04: 0000000000000000 c0000003ef9a3740 000000000000000a c0000003ef9f1c80 GPR08: c0000003ef9f1c80 00000000000004d0 0000000000000001 000000007abc6dbb GPR12: 0000019f1a2654f8 c00000000fff7480 00000000107ce2ec 000000001075fc10 GPR16: 0000000000000011 c000000000d56200 0000000000000000 000000001d8a2000 GPR20: 0000000000000000 0000000000000040 c000000000e74b48 c0000003ef9a3200 GPR24: c000000000cbc480 c0000003ef9a3740 c0000003ef9a33a0 c0000003ef9a3740 GPR28: 000000000000000a c000000074b86000 c0000003ef9f1c80 000000000000000a NIP [c000000000789578] .xfrm_resolve_and_create_bundle+0x78/0xbb4 LR [c00000000078ca48] .xfrm_bundle_lookup+0x158/0x6f8 Call Trace: [c0000003ef9a3190] [c0000003ef9a32c0] 0xc0000003ef9a32c0 (unreliable) [c0000003ef9a3330] [c00000000078ca48] .xfrm_bundle_lookup+0x158/0x6f8 [c0000003ef9a3400] [c0000000006d1a9c] .flow_cache_lookup+0x43c/0x4f4 [c0000003ef9a34e0] [c00000000078d348] .xfrm_lookup+0x260/0x6a4 [c0000003ef9a3610] [c0000000007a7edc] .ip6_dst_lookup_flow+0x8c/0xc0 [c0000003ef9a36b0] [c0000000007ca3d0] .rawv6_sendmsg+0x264/0xcc8 [c0000003ef9a3820] [c000000000758c18] .inet_sendmsg+0x98/0x110 [c0000003ef9a38c0] [c000000000694124] .sock_sendmsg+0x94/0xf4 [c0000003ef9a3a20] [c000000000694738] .___sys_sendmsg+0x340/0x350 [c0000003ef9a3c20] [c0000000006990c8] .__sys_sendmsg+0x58/0xb4 [c0000003ef9a3d00] [c0000000006dac94] .compat_sys_sendmsg+0x48/0x70 [c0000003ef9a3d90] [c0000000006db228] .compat_sys_socketcall+0x2b4/0x310 [c0000003ef9a3e30] [c0000000000005a4] syscall_exit+0x0/0x8c Instruction dump: fbc1fff0 fbe1fff8 f821fe61 7c7a1b78 7cdf3378 7c942378 7cb92b78 7cfe3b78 60000000 60000000 e93a0000 3ae10070 <e9290000> 7f43d378 7e84a378 7f25cb78 Kindly let me know if there is any patch available to fix this issue. If further details are required, I can post. Regards, Sriram