[Openswan dev] Crash in ipsec_xmit_state_delete()
David McCullough
david_mccullough at mcafee.com
Sun Feb 20 18:46:56 EST 2011
Jivin Holger Kummert lays it down ...
>
> Hello,
>
> I'm new to this list and I have a question regarding running the Openswan 2.6.32
> on Linux kernel 2.6.32, architecture is ARM IXP425. My goal is to use the hw-acceleration
> of the ixp-chip.
> In a first step I'm trying to use the sw-kernel-algorithms of the kernel, which worked
> pretty well with Openswan 2.6.32 (with klips) and linux-kernel 2.6.27.
> The ocf-module is in use.
> With the newer kernel I get a crash when only one ping-packet is transported back and forth
> through the tunnel:
>
> :~# Unable to handle kernel paging request at virtual address 6b6b6cf7
> pgd = c4b3c000
> [6b6b6cf7] *pgd=00000000
> Internal error: Oops: f3 [#1]
> last sysfs file: /sys/devices/platform/i2c-gpio.0/i2c-0/0-0014/name
> Modules linked in: ipsec serocco fwnet(P) fwcodec(P) trace(P) cryptosoft cryptodev(P) ocf(P) e100
> ixp4xx_hss ixp4xx_eth libphy max66xx at24 pca954x i2c_mux
> CPU: 0 Tainted: P (2.6.32.28 #8)
> PC is at ipsec_xmit_state_delete+0x48/0x90 [ipsec]
> LR is at poison_obj+0x40/0x50
> pc : [<bf0df048>] lr : [<c0098890>] psr: 20000013
> sp : c7821ef4 ip : 6b6b6b6b fp : c7821f04
> r10: 00000018 r9 : 0000000a r8 : 00000006
> r7 : 00000001 r6 : 00000000 r5 : c4facb38 r4 : c4facb38
> r3 : 00000004 r2 : c4d8586c r1 : 6b6b6b6b r0 : 6b6b6b6b
> Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 000039ff Table: 04b3c000 DAC: 00000017
> Process ksoftirqd/0 (pid: 3, stack limit = 0xc7820260)
> Stack: (0xc7821ef4 to 0xc7822000)
> 1ee0: c4facb98 c7821f1c c7821f08
> 1f00: bf0dd790 bf0df00c c4facb38 000003e7 c7821f38 c7821f20 bf0e29f0 bf0dd618
> 1f20: 00000000 c03bde60 c03e71d8 c7821f48 c7821f3c bf0f5188 bf0e2898 c7821f60
> 1f40: c7821f4c c004aa70 bf0f5168 c7820000 00000100 c7821f94 c7821f64 c004a6b8
> 1f60: c004a9f0 c0040bfc c0040bb8 60000013 00000000 c03e71a0 00000000 00000000
> 1f80: 00000000 00000000 c7821fa8 c7821f98 c004a788 c004a640 c7820000 c7821fc8
> 1fa0: c7821fac c004aea0 c004a750 c781bf20 00000000 c004ae40 00000000 c7821ff4
> 1fc0: c7821fcc c0059f50 c004ae4c 00000000 00000000 c7821fd4 c7821fd4 00000000
> 1fe0: 00000000 00000000 00000000 c7821ff8 c0047ed8 c0059edc afed8800 a7b50300
> Backtrace:
> [<bf0df000>] (ipsec_xmit_state_delete+0x0/0x90 [ipsec]) from [<bf0dd790>]
> (ipsec_tunnel_xsm_complete+0x184/0x19c [ipsec])
> r4:c4facb98
> [<bf0dd60c>] (ipsec_tunnel_xsm_complete+0x0/0x19c [ipsec]) from [<bf0e29f0>] (ipsec_xsm+0x164/0x190
> [ipsec])
> r5:000003e7 r4:c4facb38
> [<bf0e288c>] (ipsec_xsm+0x0/0x190 [ipsec]) from [<bf0f5188>] (ipsec_ocf_skbq_process+0x2c/0x60 [ipsec])
> r6:c03e71d8 r5:c03bde60 r4:00000000
> [<bf0f515c>] (ipsec_ocf_skbq_process+0x0/0x60 [ipsec]) from [<c004aa70>] (tasklet_action+0x8c/0xe0)
> [<c004a9e4>] (tasklet_action+0x0/0xe0) from [<c004a6b8>] (__do_softirq+0x84/0x110)
> r5:00000100 r4:c7820000
> [<c004a634>] (__do_softirq+0x0/0x110) from [<c004a788>] (do_softirq+0x44/0x60)
> [<c004a744>] (do_softirq+0x0/0x60) from [<c004aea0>] (ksoftirqd+0x60/0xe4)
> r4:c7820000
> [<c004ae40>] (ksoftirqd+0x0/0xe4) from [<c0059f50>] (kthread+0x80/0x88)
> r7:00000000 r6:c004ae40 r5:00000000 r4:c781bf20
> [<c0059ed0>] (kthread+0x0/0x88) from [<c0047ed8>] (do_exit+0x0/0x238)
> r6:00000000 r5:00000000 r4:00000000
> Code: eb3eeeb6 e5940008 e3500000 0a00000d (e590018c)
> ---[ end trace d04501fb2fd46b26 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
>
>
> The loaded modules are (roughly):
> ~# lsmod
>
> ipsec 342690 2 - Live 0xbf0d7000
> serocco 53763 0 - Live 0xbf0c2000
> cryptosoft 11819 0 - Live 0xbf059000
> cryptodev 10729 1 - Live 0xbf051000 (P)
> ocf 16785 3 ipsec,cryptosoft,cryptodev, Live 0xbf045000 (P)
> e100 31485 0 - Live 0xbf036000
> ixp4xx_hss 10620 0 - Live 0xbf02e000
> ixp4xx_eth 9876 0 - Live 0xbf026000
> libphy 13104 1 ixp4xx_eth, Live 0xbf01b000
> max66xx 11090 0 - Live 0xbf012000
> at24 4047 0 - Live 0xbf00c000
> pca954x 2504 0 - Live 0xbf006000
> i2c_mux 1466 1 pca954x, Live 0xbf000000
> version 2
>
>
> /etc/ipsec.conf
>
> config setup
> interfaces="ipsec0=eth2:1"
> klipsdebug=none
> plutodebug=none
>
> conn nessi01
> auto=start
> ike=aes256-sha1;modp1024
> phase2alg=aes256-sha1
> authby=secret
> left=11.0.0.1
> leftnexthop=0.0.0.0
> leftsubnet=20.0.0.0/24
> right=11.0.0.2
> rightsubnet=10.0.0.1/32
> compress=no
> dpddelay=10
> dpdtimeout=30
> dpdaction=restart
>
>
> When I look at the function where the crash happens, I ask myself if
> there is a wrong sequence of commands:
>
> ipsec_xmit_state_delete (struct ipsec_xmit_state *ixs)
> {
> if (unlikely (! ixs))
> return;
>
> spin_lock_bh (&ixs_cache_lock);
> ixs_cache_allocated_count--;
> kmem_cache_free (ixs_cache_allocator, ixs);
> #if defined(HAS_NETIF_QUEUE) || defined (HAVE_NETIF_QUEUE)
> if (ixs->dev && netif_queue_stopped(ixs->dev))
> netif_wake_queue(ixs->dev);
> #else /* defined(HAS_NETIF_QUEUE) || defined (HAVE_NETIF_QUEUE) */
> if (ixs->dev)
> ixs->dev->tbusy = 0;
> #endif /* defined(HAS_NETIF_QUEUE) || defined (HAVE_NETIF_QUEUE) */
> spin_unlock_bh (&ixs_cache_lock);
> }
>
> Isn't the kmem_cache_free()-call too early? After the free the function accesses
> the freed variable 'ixs'.
>
> When I exchange those (i.e. move the free-call after the access), I get another crash:
>
> klips_debug:ipsec_xmit_state_delete(obj 0xc5202b38)
>
> slab: double free detected in cache 'size-256', objp c4cfa060
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> Backtrace:
> [<c0099954>] (slab_put_obj+0x0/0x9c) from [<c009a520>] (free_block+0xcc/0x174)
> r9:00000002 r8:c4cfa060 r7:00000000 r6:c78006c0 r5:c7802320
> r4:c4cfa000
> [<c009a454>] (free_block+0x0/0x174) from [<c009b16c>] (drain_array+0xac/0xe0)
> [<c009b0c0>] (drain_array+0x0/0xe0) from [<c009b208>] (cache_reap+0x68/0x134)
> r6:00000000 r5:c78006c0 r4:c7802320
> [<c009b1a0>] (cache_reap+0x0/0x134) from [<c0056408>] (run_workqueue+0x98/0x118)
> [<c0056370>] (run_workqueue+0x0/0x118) from [<c005653c>] (worker_thread+0xb4/0xc4)
>
> I enabled Debugging in slab to see this.
>
> Did anyone see this behavior before?
Haven't seen that but the code is definately wrong IMO.
Try the attached patch.
Thanks,
Davidm
--
David McCullough, david_mccullough at mcafee.com, Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ixs-dev-used-after-free.diff
Type: text/x-diff
Size: 1090 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/dev/attachments/20110221/efe2f48c/attachment.bin
More information about the Dev
mailing list