From nobody@FreeBSD.org  Mon Jan 23 08:08:36 2012
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id E746A106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 23 Jan 2012 08:08:36 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id D4ED98FC08
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 23 Jan 2012 08:08:36 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q0N88aMW021034
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 23 Jan 2012 08:08:36 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id q0N88a0I021033;
	Mon, 23 Jan 2012 08:08:36 GMT
	(envelope-from nobody)
Message-Id: <201201230808.q0N88a0I021033@red.freebsd.org>
Date: Mon, 23 Jan 2012 08:08:36 GMT
From: "Eugene M. Zheganin" <eugene@zhegan.in>
To: freebsd-gnats-submit@FreeBSD.org
Subject: immediate crash after the start of ipsec processing
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         164400
>Category:       kern
>Synopsis:       [ipsec] immediate crash after the start of ipsec processing
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bz
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan 23 08:10:13 UTC 2012
>Closed-Date:    Wed Jul 25 19:31:07 UTC 2012
>Last-Modified:  Wed Jul 25 19:31:07 UTC 2012
>Originator:     Eugene M. Zheganin
>Release:        9.0-RELEASE
>Organization:
RealService LLC
>Environment:
FreeBSD  9.0-RELEASE FreeBSD 9.0-RELEASE #1: Sun Jan 22 21:59:51 MSK 2012     emz@moscow-alpha:/usr/obj/usr/src/sys/MOSCOW  amd64
>Description:
There's a HA-cluster of 2 freebsd running ipsec+gre and a butch of tunnels to branch offices with OSPF. Both were running 8.2-RELEASE and/or different versions of 8.2-STABLE. Since this setup wasn't that stable I was constantly upgrading one of the nodes to a recent -STABLE. After a December -STABLE first node was crashing every hour, so I decided to test it with the memtest86+ (4.20). One week of running memtest gave no errors. So I upgraded to 9.0 and built a debug kernel with WITNESS/INVARIANTS and stuff.

OSPF is served by quagga.
ISAKMP is served by security/ipsec-tools.

Now I have an immediate crash after a carp(4) with public address for gre tunnels and ipsec processing is switching to MASTER. Without it it runs fine.

The crash is reproduceable (at least I tested 3 times and got 3 craches). BTs are identical ( I compared each screen first and last line, so only first set of screens is referenced here).
This host has an ipkvm (and YES, I can give access to it if needed, it lives on a public address, you will need a working java browser plugin to use it), so here are the screens of this trap happening:

http://tech.norma.perm.ru/files/screen01.jpeg
http://tech.norma.perm.ru/files/screen02.jpeg
http://tech.norma.perm.ru/files/screen03.jpeg
http://tech.norma.perm.ru/files/screen04.jpeg
http://tech.norma.perm.ru/files/screen05.jpeg

Furthermore, when running with WITNESS on this node produces the following output immediately after loading a set of pf rules:

http://tech.hq.norma.perm.ru/files/lor.txt

This output is always the same too.

ipsec.conf:
[emz@:~]> cat /etc/ipsec.conf 
spdflush;                                                                                                               
                                                                                                                        
#
# Moscow, Schelkovskoye, Megaton
#
                                                                                                                        
spdadd 94.159.37.114 89.250.210.69 gre -P out ipsec esp/transport/94.159.37.114-89.250.210.69/require ah/transport/94.159.37.114-89.250.210.69/require;                  
spdadd 89.250.210.69 94.159.37.114 gre -P in ipsec esp/transport/89.250.210.69-94.159.37.114/require ah/transport/89.250.210.69-94.159.37.114/require;

#
# Moscow, Pervomayskaya, MGTS
#

spdadd 109.252.242.9 94.159.37.114 gre -P in ipsec esp/transport/109.252.242.9-94.159.37.114/require ah/transport/109.252.242.9-94.159.37.114/require;
spdadd 94.159.37.114 109.252.242.9 gre -P out ipsec esp/transport/94.159.37.114-109.252.242.9/require ah/transport/94.159.37.114-109.252.242.9/require;

#
# Moscow, Privolnaya, 70
#

spdadd 82.142.171.58 94.159.37.114 gre -P in ipsec esp/transport/82.142.171.58-94.159.37.114/require ah/transport/82.142.171.58-94.159.37.114/require;
spdadd 94.159.37.114 82.142.171.58 gre -P out ipsec esp/transport/94.159.37.114-82.142.171.58/require ah/transport/94.159.37.114-82.142.171.58/require;

#
# Moscow, Lermontovsky, 2
#

spdadd 79.120.78.118 94.159.37.114 gre -P in ipsec esp/transport/79.120.78.118-94.159.37.114/require ah/transport/79.120.78.118-94.159.37.114/require;
spdadd 94.159.37.114 79.120.78.118 gre -P out ipsec esp/transport/94.159.37.114-79.120.78.118/require ah/transport/94.159.37.114-79.120.78.118/require;

#
# Moscow, Tashkentskaya 12-20
#

spdadd 79.120.80.66 94.159.37.114 gre -P in ipsec esp/transport/79.120.80.66-94.159.37.114/require ah/transport/79.120.80.66-94.159.37.114/require;
spdadd 94.159.37.114 79.120.80.66 gre -P out ipsec esp/transport/94.159.37.114-79.120.80.66/require ah/transport/94.159.37.114-79.120.80.66/require;

#
# Moscow, Baykalskaya 50/7
#

spdadd 213.33.223.158 94.159.37.114 gre -P in ipsec esp/transport/213.33.223.158-94.159.37.114/require ah/transport/213.33.223.158-94.159.37.114/require;
spdadd 94.159.37.114 213.33.223.158 gre -P out ipsec esp/transport/94.159.37.114-213.33.223.158/require ah/transport/94.159.37.114-213.33.223.158/require;


#
# Moscow, Bratyslavskaya 15-1
#

#spdadd 212.46.203.106 94.159.37.114 gre -P in ipsec esp/transport/212.46.203.106-94.159.37.114/require ah/transport/212.46.203.106-94.159.37.114/require;
#spdadd 94.159.37.114 212.46.203.106 gre -P out ipsec esp/transport/94.159.37.114-212.46.203.106/require ah/transport/94.159.37.114-212.46.203.106/require;

#add 212.46.203.106 94.159.37.114 esp 0x10001 -m transport -E des-cbc 0xffffffffffffffff;
#add 94.159.37.114 212.46.203.106 esp 0x10002 -m transport -E des-cbc 0xffffffffffffffff;

#add 212.46.203.106 94.159.37.114 ah 0x10003 -m transport -A keyed-md5 "xxxxxxxxxxxxxxxx";
#add 94.159.37.114 212.46.203.106 ah 0x10004 -m transport -A keyed-md5 "xxxxxxxxxxxxxxxx";

racoon.conf:

[emz@:~]# cat /usr/local/etc/racoon/racoon.conf 
path pre_shared_key "/usr/local/etc//racoon/psk.txt";

# "padding" defines some padding parameters.  You should not touch these.
padding {
    maximum_length 20;<># maximum padding length.
    randomize off;      # enable randomize length.
    strict_check off;   # enable strict check.
    exclusive_tail off; # extract last one octet.
}

# if no listen directive is specified, racoon will listen on all
# available interface addresses.
listen {
    isakmp 94.159.37.114 [500];
    strict_address;     # requires that all addresses must be bound.
}

# Specify various default timers.
timer {
    # These value can be changed per remote node.
    counter 5;  # maximum trying count to send.
    interval 20 sec;    # maximum interval to resend.
    persend 1;          # the number of packets per send.
    # maximum time to wait for completing each phase.
    phase1 30 sec;
    phase2 15 sec;
}

#
# Kosm65, wizard, PiC
#

remote 89.250.210.69 {
    exchange_mode main;
    lifetime time 1 hour;
    my_identifier address 94.159.37.114;
    peers_identifier address 89.250.210.69;
    passive off;
    proposal_check obey;
    dpd_delay 20;
    proposal {
        encryption_algorithm des;
        hash_algorithm md5;
        authentication_method pre_shared_key;
        dh_group modp768;
    }
}

#
# Moscow, Permovayskaya10/5, MGTS
#

remote 109.252.242.9 {
    exchange_mode main;
    lifetime time 1 hour;
    my_identifier address 94.159.37.114;
    peers_identifier address 109.252.242.9;
    passive off;
    proposal_check obey;
    dpd_delay 20;
    proposal {
        encryption_algorithm des;
        hash_algorithm md5;
        authentication_method pre_shared_key;
        dh_group modp768;
    }
}

#
# Moscow, Privolnaya, 70
#

remote 82.142.171.58 {
    exchange_mode main;
    lifetime time 1 hour;
    my_identifier address 94.159.37.114;
    peers_identifier address 82.142.171.58;
    passive off;
    proposal_check obey;
    dpd_delay 20;
    proposal {
        encryption_algorithm des;
        hash_algorithm md5;
        authentication_method pre_shared_key;
        dh_group modp768;
    }
}

#
# Moscow, Lermontovsky, 2
#

remote 79.120.78.118 {
    exchange_mode main;
    lifetime time 1 hour;
    my_identifier address 94.159.37.114;
    peers_identifier address 79.120.78.118;
    passive off;
    proposal_check obey;
    dpd_delay 20;
    proposal {
        encryption_algorithm des;
        hash_algorithm md5;
        authentication_method pre_shared_key;
        dh_group modp768;
    }
}

#
# Moscow, Baykalskaya 50/7
#

remote 213.33.223.158 {
    exchange_mode main;
    lifetime time 1 hour;
    my_identifier address 94.159.37.114;
    peers_identifier address 213.33.223.158;
    passive off;
    proposal_check obey;
    dpd_delay 20;
    proposal {
        encryption_algorithm des;
        hash_algorithm md5;
        authentication_method pre_shared_key;
        dh_group modp768;
    }
}

#
# Moscow, Tashkentskaya 12-20
#

remote 79.120.80.66 {
    exchange_mode main;
    lifetime time 1 hour;
    my_identifier address 94.159.37.114;
    peers_identifier address 79.120.80.66;
    passive off;
    proposal_check obey;
    dpd_delay 20;
    proposal {
        encryption_algorithm des;
        hash_algorithm md5;
        authentication_method pre_shared_key;
        dh_group modp768;
    }
}

#
# Moscow, Bratyslavskaya 15-1
#

#remote 212.46.203.106 {
#    exchange_mode main;
#    lifetime time 1 hour;
#    my_identifier address 94.159.37.114;
#    peers_identifier address 212.46.203.106;
#    passive off;
#    proposal_check obey;
#    dpd_delay 20;
#    proposal {
#       encryption_algorithm des;
#        hash_algorithm md5;
#        authentication_method pre_shared_key;
#        dh_group modp768;
#    }
#}


#
# kosm65, wizard, PiC
#

sainfo address 89.250.210.69 [500] 47 address 94.159.37.114 [500] 47 {
    pfs_group modp768;
    lifetime time 60 min;
    encryption_algorithm blowfish;
    authentication_algorithm hmac_md5;
    compression_algorithm deflate;
}

sainfo address 94.159.37.114 [500] 47 address 89.250.210.69 [500] 47 {
    pfs_group modp768;
    lifetime time 60 min;
    encryption_algorithm blowfish;
    authentication_algorithm hmac_md5;
    compression_algorithm deflate;
}

#
# Moscow, Pervomayskaya, 10/5, MGTS
#

sainfo address 94.159.37.114 [500] 47 address 109.252.242.9 [500] 47 {
    pfs_group modp768;
    lifetime time 60 min;
    encryption_algorithm des;
    authentication_algorithm hmac_sha1, non_auth;
    compression_algorithm deflate;
}

sainfo address 109.252.242.9 [500] 47 address 94.159.37.114 [500] 47 {
    pfs_group modp768;
    lifetime time 60 min;
    encryption_algorithm des;
    authentication_algorithm hmac_sha1, non_auth;
    compression_algorithm deflate;
}

#
# Moscow, Privolnaya, 70
#

sainfo address 94.159.37.114 [500] 47 address 82.142.171.58 [500] 47 {
    pfs_group modp768;
    lifetime time 60 min;
    encryption_algorithm des;
    authentication_algorithm hmac_sha1, non_auth;
    compression_algorithm deflate;
}

sainfo address 82.142.171.58 [500] 47 address 94.159.37.114 [500] 47 {
    pfs_group modp768;
    lifetime time 60 min;
    encryption_algorithm des;
    authentication_algorithm hmac_sha1, non_auth;
    compression_algorithm deflate;
}

#
# Moscow, Lermontovsky, 2
#

sainfo address 94.159.37.114 [500] 47 address 79.120.78.118 [500] 47 {
    pfs_group modp768;
    lifetime time 60 min;
    encryption_algorithm des;
    authentication_algorithm hmac_sha1, non_auth;
    compression_algorithm deflate;
}

sainfo address 79.120.78.118 [500] 47 address 94.159.37.114 [500] 47 {
    pfs_group modp768;
    lifetime time 60 min;
    encryption_algorithm des;
    authentication_algorithm hmac_sha1, non_auth;
    compression_algorithm deflate;
}

#
# Moscow, Tashkentskaya 12-20
#

sainfo address 94.159.37.114 [500] 47 address 79.120.80.66 [500] 47 {
    pfs_group modp768;
    lifetime time 60 min;
    encryption_algorithm des;
    authentication_algorithm hmac_sha1, non_auth;
    compression_algorithm deflate;
}

sainfo address 79.120.80.66 [500] 47 address 94.159.37.114 [500] 47 {
    pfs_group modp768;
    lifetime time 60 min;
    encryption_algorithm des;
    authentication_algorithm hmac_sha1, non_auth;
    compression_algorithm deflate;
}

#
# Moscow, Baykalskaya 50/7
#

sainfo address 94.159.37.114 [500] 47 address 213.33.223.158 [500] 47 {
    pfs_group modp768;
    lifetime time 60 min;
    encryption_algorithm des;
    authentication_algorithm hmac_sha1, non_auth;
    compression_algorithm deflate;
}

sainfo address 213.33.223.158 [500] 47 address 94.159.37.114 [500] 47 {
    pfs_group modp768;
    lifetime time 60 min;
    encryption_algorithm des;
    authentication_algorithm hmac_sha1, non_auth;
    compression_algorithm deflate;
}

#
# Moscow, Bratyslavskaya 15-1
#

#sainfo address 94.159.37.114 [500] 47 address 212.46.203.106 [500] 47 {
#    pfs_group modp768;
#    lifetime time 60 min;
#    encryption_algorithm des;
#    authentication_algorithm hmac_sha1, non_auth;
#    compression_algorithm deflate;
#}

#sainfo address 212.46.203.106 [500] 47 address 94.159.37.114 [500] 47 {
#    pfs_group modp768;
#    lifetime time 60 min;
#    encryption_algorithm des;
#    authentication_algorithm hmac_sha1, non_auth;
#    compression_algorithm deflate;
#}
>How-To-Repeat:
Get a FreeBSD 9.0, get an ipsec setup, get a bunch of gre tunnels, get a quagga (trap mentions its ospfd), and probably get a carp(4) interface (not sure if it will trap without; at least I did not test it without a carp(4)).
>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Jan 23 08:29:29 UTC 2012 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=164400 

From: "Eugene M. Zheganin" <eugene@zhegan.in>
To: bug-followup@FreeBSD.org, eugene@zhegan.in
Cc:  
Subject: Re: kern/164400: immediate crash after the start of ipsec processing
Date: Mon, 23 Jan 2012 14:22:59 +0600

 I've re-read it and I found one phrase that can cause misunderstanding:
 
 'Without it it runs fine.'
 
 I should write 'without switching to master and starting ipsec 
 processing from branches'.
 

From: "Eugene M. Zheganin" <emz@norma.perm.ru>
To: bug-followup@FreeBSD.org, eugene@zhegan.in
Cc:  
Subject: Re: kern/164400: [ipsec] immediate crash after the start of ipsec
 processing
Date: Wed, 29 Feb 2012 14:03:55 +0600

 This is reproduceable on smaller amount of configs.
 Right now I've built a test installation of nanobsd 9.0, which is also 
 crashing under the same conditions.
 
 For example:
 
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0x60
 fault code              = supervisor read, page not present
 instruction pointer     = 0x20:0xc0980d89
 stack pointer           = 0x28:0xccf245cc
 frame pointer           = 0x28:0xccf245f4
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                          = DPL 0, pres 1, def32 1, gran 1
 processor eflags        = interrupt enabled, resume, IOPL = 0
 current process         = 2099 (ping)
 trap number             = 12
 panic: page fault
 KDB: stack backtrace:
 #0 0xc07d35f8 at kdb_backtrace+0x48
 #1 0xc07a3163 at panic+0xf3
 #2 0xc0a8a492 at trap_fatal+0x232
 #3 0xc0a8a77b at trap_pfault+0x1ab
 #4 0xc0a8b477 at trap+0x367
 #5 0xc0a766cc at calltrap+0x6
 #6 0xc098fe0f at esp_output_cb+0x19f
 #7 0xc099f6f7 at crypto_done+0xf7
 #8 0xc09a1c33 at swcr_process+0x83
 #9 0xc09a06d7 at crypto_invoke+0x67
 #10 0xc09a1548 at crypto_dispatch+0xe8
 #11 0xc0990457 at esp_output+0x577
 #12 0xc09810be at ipsec4_process_packet+0x1ee
 #13 0xc08c3e03 at ip_ipsec_output+0x153
 #14 0xc08c6406 at ip_output+0x426
 #15 0xc2671259 at gre_output+0x469
 #16 0xc08c6b87 at ip_output+0xba7
 #17 0xc08c73dc at rip_output+0x24c
 Uptime: 1m45s
 Automatic reboot in 15 seconds - press a key on the console to abort
 
 I can say also that 'current process' is simply a process that sends the 
 packet which crashes the system. The crash occurs on some of the first 
 packets immidialety after establishing SA.

From: VANHULLEBUS Yvan <vanhu@FreeBSD.org>
To: "Eugene M. Zheganin" <emz@norma.perm.ru>
Cc: bug-followup@FreeBSD.org
Subject: Re:  kern/164400: [ipsec] immediate crash after the start of ipsec processing
Date: Wed, 29 Feb 2012 11:32:48 +0100

 Hi.
 
 Can you produce the same crash / backtrace, but with a DEBUG kernel ?
 
 
 Thanks,
 
 Yvan.

From: "Eugene M. Zheganin" <emz@norma.perm.ru>
To: bug-followup@FreeBSD.org, eugene@zhegan.in
Cc:  
Subject: Re: kern/164400: [ipsec] immediate crash after the start of ipsec
 processing
Date: Thu, 01 Mar 2012 10:38:38 +0600

 yeah, I'm working on it. will do today.
 
 Right now I localized this crash to a minimal configuration. And it 
 looks like ipsec is simply broken, don't know if this is ah or esp or 
 only when both, but it crashes with this config:
 
 ipsec.conf
 ===Cut===
 spdflush;
 
 #
 # HQ, Wizard, Test
 #
 
 spdadd 192.168.3.134 192.168.3.24 gre -P out ipsec 
 esp/transport/192.168.3.134-192.168.3.24/require 
 ah/transport/192.168.3.134-192.168.3.24/require;
 spdadd 192.168.3.24 192.168.3.134 gre -P in ipsec 
 esp/transport/192.168.3.24-192.168.3.134/require 
 ah/transport/192.168.3.24-192.168.3.134/require;
 
 add 192.168.3.134 192.168.3.24 esp 0x10001 -m transport -E des-cbc 
 0xffffffffffffffff;
 add 192.168.3.24 192.168.3.134 esp 0x10002 -m transport -E des-cbc 
 0xffffffffffffffff;
 
 add 192.168.3.134 192.168.3.24 ah 0x10003 -m transport -A keyed-md5 
 "xxxxxxxxxxxxxxxx";
 add 192.168.3.24 192.168.3.134 ah 0x10004 -m transport -A keyed-md5 
 "xxxxxxxxxxxxxxxx";
 ===Cut===
 
 Tunnel:
 
 gre0: flags=b051<UP,POINTOPOINT,RUNNING,LINK0,LINK1,MULTICAST> metric 0 
 mtu 1476
          tunnel inet 192.168.3.134 --> 192.168.3.24
          inet 172.16.3.63 --> 172.16.3.62 netmask 0xffffffff
          inet6 fe80::20d:b9ff:fe20:d980%gre0 prefixlen 64 tentative 
 scopeid 0x9
          nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
 
 192.168.3.134 is a panicbox IP. 192.168.3.24 is a real IP existing on 
 the network, but it has no SA installed (I guess this can be any 
 address, even nonexisting, because this is static IPSEC, as you can see).
 
 First packet is sent and system crashes.

From: "Eugene M. Zheganin" <emz@norma.perm.ru>
To: bug-followup@FreeBSD.org, eugene@zhegan.in
Cc:  
Subject: Re: kern/164400: [ipsec] immediate crash after the start of ipsec
 processing
Date: Fri, 02 Mar 2012 13:52:09 +0600

 sorry for the delay.
 the thing is, 9.0 with pf enabled is almost useless when the kernel is 
 build with WITNESS/WITNESS_KDB - it keeps witnessing to KDB in infinite 
 cycle after entering multiuser.
 
 I took the dump with the debug kernel.
 
 Here's the stuff:
 
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0x60
 fault code              = supervisor read, page not present
 instruction pointer     = 0x20:0xc0965a55
 stack pointer           = 0x28:0xccf145a0
 frame pointer           = 0x28:0xccf145c8
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                          = DPL 0, pres 1, def32 1, gran 1
 processor eflags        = interrupt enabled, resume, IOPL = 0
 current process         = 2010 (ping)
 trap number             = 12
 panic: page fault
 KDB: stack backtrace:
 db_trace_self_wrapper(c0b1382c,70797420,78302065,a6231,bfbfe518,...) at 
 db_trace_self_wrapper+0x26
 kdb_backtrace(c0b0fa75,c0bf5900,c0aaaeaa,ccf1444c,ccf1444c,...) at 
 kdb_backtrace+0x2a
 panic(c0aaaeaa,c0b5fa29,c28af770,1,1,...) at panic+0xaf
 trap_fatal(97d8,4fca2d23,4,ccf144b0,60,...) at trap_fatal+0x2f3
 trap_pfault(ccf144e2,6f20,40000,ccf144f4,c28a8000,...) at trap_pfault+0xac
 trap(ccf14560) at trap+0x495
 calltrap() at calltrap+
 <3>stray irq7
 0x6
 --- trap 0xc, eip = 0xc0965a55, esp = 0xccf145a0, ebp = 0xccf145c8 ---
 ipsec_process_done(c286fc00,c28f3880,3a3,4,c0b0e147,...) at 
 ipsec_process_done+0x195
 esp_output_cb(c28fa000,91214f13,c0bc1220,ccf14630,c098c8a4,...) at 
 esp_output_cb+0x1aa
 crypto_done(c28fa000,c286fcd4,ccf146c8,8,ccf147ec,...) at crypto_done+0xb7
 swcr_process(c2053680,c28fa000,0,2,c2255740,...) at swcr_process+0x12ce
 crypto_invoke(1
 <3>stray irq7
 01,0,c0bc1220,c28f8d80,c2255740,...) at crypto_invoke+0x141
 crypto_dispatch(c28fa000,c0b3ef45,371,ccf148a7,c28f6300,...) at 
 crypto_dispatch+0x64
 esp_output(c286fc00,c28f3880,0,14,9,...) at esp_output+0x5a6
 ipsec4_process_packet(c286fc00,c28f3880,1,0,0,...) at 
 ipsec4_process_packet+0x29f
 ip_ipsec_output(ccf149b0,0,ccf14a00,ccf149b8,201,...) at ip_ipsec_
 <3>stray irq7
 output+0x1e0
 ip_output(c286fc00,0,c2818220,1,0,...) at ip_output+0x810
 gre_output(c20f7400,c286fc00,ccf14ab4,ccf14aa4,c280d9d8,...) at 
 gre_output+0x469
 ip_output(c286fc00,0,0,20,0,...) at ip_output+0xaa6
 rip_output(c286fc00,c2686b60,3e0310ac,ccf14b7c,c07f5d8d,...) at 
 rip_output+0x2ff
 rip_send(c2686b60,0,c286fc00,c284c320,0,...) at rip_send+0x76
 sosend_generic(c2686b60,c284c320,ccf14bd4,0,0,...) at sosend_generic+0x50d
 sosend(c2686b60,c284c320,ccf14bd4,0,0,...) at sosend+0x3f
 kern_sendit(c28af5c0,3,ccf14c48,0,0,...) at kern_sendit+0x1d4
 sendit(0,c284c320,10,ccf14c64,1,...) at sendit+0xb1
 sys_sendto(c28af5c0,ccf14cec,c,c,246,...) at sys_sendto+0x48
 syscall(ccf14d28) at syscall+0x284
 Xint0x80_syscall() at Xint0x80_syscall+0x21
 --- syscall (133, FreeBSD ELF32, sys_sendto), eip = 0x2818b237, esp = 
 0xbfbee70c, ebp = 0xbfbee748 ---
 Uptime: 10m29s
 Physical memory: 243 MB
 Dumping 42 MB: 27 11
 
 No symbol "stopped_cpus" in current context.
 No symbol "stoppcbs" in current context.
 Reading symbols from /boot/kernel/if_gre.ko...done.
 Loaded symbols for /boot/kernel/if_gre.ko
 #0  doadump (textdump=1) at pcpu.h:244
 244     pcpu.h: No such file or directory.
          in pcpu.h
 (kgdb) bt
 #0  doadump (textdump=1) at pcpu.h:244
 #1  0xc078cf75 in kern_reboot (howto=260) at 
 /usr/src/sys/kern/kern_shutdown.c:442
 #2  0xc078c8ee in panic (fmt=Variable "fmt" is not available.
 ) at /usr/src/sys/kern/kern_shutdown.c:607
 #3  0xc0a6cf53 in trap_fatal (frame=0xccf14560, eva=96) at 
 /usr/src/sys/i386/i386/trap.c:975
 #4  0xc0a6d00c in trap_pfault (frame=0xccf14560, usermode=0, eva=96) at 
 /usr/src/sys/i386/i386/trap.c:839
 #5  0xc0a6dc45 in trap (frame=0xccf14560) at 
 /usr/src/sys/i386/i386/trap.c:558
 #6  0xc0a58e1c in calltrap () at /usr/src/sys/i386/i386/exception.s:168
 #7  0xc0965a55 in ipsec_process_done (m=0xc286fc00, isr=0xc28f3880) at 
 /usr/src/sys/netipsec/ipsec_output.c:170
 #8  0xc0974dba in esp_output_cb (crp=0xc28fa000) at 
 /usr/src/sys/netipsec/xform_esp.c:1007
 #9  0xc09848f7 in crypto_done (crp=0xc28fa000) at 
 /usr/src/sys/opencrypto/crypto.c:1156
 #10 0xc098777e in swcr_process (dev=0xc2053680, crp=0xc28fa000, hint=0) 
 at /usr/src/sys/opencrypto/cryptosoft.c:1054
 #11 0xc0985991 in crypto_invoke (cap=0xc2053680, crp=0xc28fa000, hint=0) 
 at cryptodev_if.h:53
 #12 0xc0985db4 in crypto_dispatch (crp=0xc28fa000) at 
 /usr/src/sys/opencrypto/crypto.c:806
 #13 0xc0975416 in esp_output (m=0xc286fc00, isr=0xc28f3880, mp=0x0, 
 skip=20, protoff=9)
      at /usr/src/sys/netipsec/xform_esp.c:907
 #14 0xc0965e2f in ipsec4_process_packet (m=0xc286fc00, isr=0xc28f3880, 
 flags=1, tunalready=0)
      at /usr/src/sys/netipsec/ipsec_output.c:580
 #15 0xc08b09d0 in ip_ipsec_output (m=0xccf149b0, inp=0x0, 
 flags=0xccf14a00, error=0xccf149b8)
      at /usr/src/sys/netinet/ip_ipsec.c:353
 #16 0xc08b2680 in ip_output (m=0xc286fc00, opt=0x0, ro=0xc2818220, 
 flags=1, imo=0x0, inp=0x0)
      at /usr/src/sys/netinet/ip_output.c:480
 #17 0xc28e1259 in gre_output () from /boot/kernel/if_gre.ko
 #18 0xc08b2916 in ip_output (m=0xc286fc00, opt=0x0, ro=0xccf14aa4, 
 flags=Variable "flags" is not available.
 ) at /usr/src/sys/netinet/ip_output.c:631
 #19 0xc08b468f in rip_output (m=0xc286fc00, so=0xc2686b60, 
 dst=1040388268) at /usr/src/sys/netinet/raw_ip.c:517
 #20 0xc08b4776 in rip_send (so=0xc2686b60, flags=0, m=0xc286fc00, 
 nam=0xc284c320, control=0x0, td=0xc28af5c0)
      at /usr/src/sys/netinet/raw_ip.c:994
 #21 0xc07f5d8d in sosend_generic (so=0xc2686b60, addr=0xc284c320, 
 uio=0xccf14bd4, top=0xc286fc00, control=0x0,
      flags=0, td=0xc28af5c0) at /usr/src/sys/kern/uipc_socket.c:1303
 #22 0xc07f159f in sosend (so=0xc2686b60, addr=0xc284c320, 
 uio=0xccf14bd4, top=0x0, control=0x0, flags=0, td=0xc28af5c0)
      at /usr/src/sys/kern/uipc_socket.c:1347
 #23 0xc07fbb44 in kern_sendit (td=0xc28af5c0, s=3, mp=0xccf14c48, 
 flags=0, control=0x0, segflg=UIO_USERSPACE)
      at /usr/src/sys/kern/uipc_syscalls.c:810
 #24 0xc07fbd51 in sendit (td=0xc28af5c0, s=3, mp=0xccf14c48, flags=0) at 
 /usr/src/sys/kern/uipc_syscalls.c:738
 #25 0xc07fbe68 in sys_sendto (td=0xc28af5c0, uap=0xccf14cec) at 
 /usr/src/sys/kern/uipc_syscalls.c:862
 #26 0xc0a6d414 in syscall (frame=0xccf14d28) at subr_syscall.c:131
 #27 0xc0a58e81 in Xint0x80_syscall () at 
 /usr/src/sys/i386/i386/exception.s:266
 #28 0x00000033 in ?? ()
 Previous frame inner to this frame (corrupt stack?)

From: "Andrew A. Khlebutin" <ak@dartit.ru>
To: bug-followup@FreeBSD.org, eugene@zhegan.in
Cc:  
Subject: Re: kern/164400: [ipsec] immediate crash after the start of ipsec processing
Date: Fri, 2 Mar 2012 16:54:23 +0600

 Hello,
 
 I have the similar problem. 
 
 paco.zelan dumped core - see /var/crash/vmcore.3
 
 Fri Mar  2 16:26:13 YEKT 2012
 
 FreeBSD paco.zelan 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Fri Mar  2 14:19:01 YEKT 2012     root@paco.zelan:/usr/obj/usr/src/sys/paco  amd64
 
 panic: page fault
 
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for details.
 This GDB was configured as "amd64-marcel-freebsd"...
 
 Unread portion of the kernel message buffer:
 panic: page fault
 cpuid = 1
 KDB: stack backtrace:
 #0 0xffffffff80797bbe at kdb_backtrace+0x5e
 #1 0xffffffff80761f37 at panic+0x187
 #2 0xffffffff80a88250 at trap_fatal+0x290
 #3 0xffffffff80a88599 at trap_pfault+0x1f9
 #4 0xffffffff80a88a5f at trap+0x3df
 #5 0xffffffff80a72f8f at calltrap+0x8
 #6 0xffffffff8094fc31 at esp_output_cb+0x1a1
 #7 0xffffffff80968832 at crypto_done+0x102
 #8 0xffffffff8096c3e7 at swcr_process+0x1d7
 #9 0xffffffff809696bb at crypto_invoke+0x6b
 #10 0xffffffff8096a4eb at crypto_dispatch+0xfb
 #11 0xffffffff80950282 at esp_output+0x5a2
 #12 0xffffffff80940d98 at ipsec4_process_packet+0x1f8
 #13 0xffffffff808822e3 at ip_ipsec_output+0x173
 #14 0xffffffff80883ee1 at ip_output+0x541
 #15 0xffffffff8087f0e9 at icmp_reflect+0x339
 #16 0xffffffff8087f677 at icmp_input+0x257
 #17 0xffffffff80881bcd at ip_input+0x23d
 Uptime: 27m58s
 Dumping 1149 out of 8155 MB:..2%..12%..21%..31%..41%..51%..62%..72%..81%..91%
 
 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/zfs.ko
 Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/opensolaris.ko
 Reading symbols from /boot/kernel/geom_linux_lvm.ko...Reading symbols from /boot/kernel/geom_linux_lvm.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/geom_linux_lvm.ko
 Reading symbols from /boot/kernel/ng_ubt.ko...Reading symbols from /boot/kernel/ng_ubt.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/ng_ubt.ko
 Reading symbols from /boot/kernel/ng_hci.ko...Reading symbols from /boot/kernel/ng_hci.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/ng_hci.ko
 Reading symbols from /boot/kernel/ng_bluetooth.ko...Reading symbols from /boot/kernel/ng_bluetooth.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/ng_bluetooth.ko
 Reading symbols from /boot/modules/vboxdrv.ko...done.
 Loaded symbols for /boot/modules/vboxdrv.ko
 Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/ng_socket.ko
 Reading symbols from /boot/kernel/ng_mppc.ko...Reading symbols from /boot/kernel/ng_mppc.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/ng_mppc.ko
 Reading symbols from /boot/kernel/rc4.ko...Reading symbols from /boot/kernel/rc4.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/rc4.ko
 Reading symbols from /boot/kernel/ng_iface.ko...Reading symbols from /boot/kernel/ng_iface.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/ng_iface.ko
 Reading symbols from /boot/kernel/ng_ppp.ko...Reading symbols from /boot/kernel/ng_ppp.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/ng_ppp.ko
 Reading symbols from /boot/kernel/ng_tee.ko...Reading symbols from /boot/kernel/ng_tee.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/ng_tee.ko
 Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/ng_ether.ko
 Reading symbols from /boot/kernel/ng_pppoe.ko...Reading symbols from /boot/kernel/ng_pppoe.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/ng_pppoe.ko
 Reading symbols from /boot/kernel/ng_nat.ko...Reading symbols from /boot/kernel/ng_nat.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/ng_nat.ko
 Reading symbols from /boot/kernel/ng_tcpmss.ko...Reading symbols from /boot/kernel/ng_tcpmss.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/ng_tcpmss.ko
 done.
 Loaded symbols for /boot/kernel/ng_tcpmss.ko
 #0  doadump (textdump=Variable "textdump" is not available.
 ) at pcpu.h:224
 224     pcpu.h: No such file or directory.
         in pcpu.h
 (kgdb) #0  doadump (textdump=Variable "textdump" is not available.
 ) at pcpu.h:224
 #1  0xffffffff80761a75 in kern_reboot (howto=260)
     at /usr/src/sys/kern/kern_shutdown.c:442
 #2  0xffffffff80761f21 in panic (fmt=Variable "fmt" is not available.
 )
     at /usr/src/sys/kern/kern_shutdown.c:607
 #3  0xffffffff80a88250 in trap_fatal (frame=0xc, eva=Variable "eva" is not available.
 )
     at /usr/src/sys/amd64/amd64/trap.c:819
 #4  0xffffffff80a88599 in trap_pfault (frame=0xffffff800026b2a0, usermode=0)
     at /usr/src/sys/amd64/amd64/trap.c:735
 #5  0xffffffff80a88a5f in trap (frame=0xffffff800026b2a0)
     at /usr/src/sys/amd64/amd64/trap.c:474
 #6  0xffffffff80a72f8f in calltrap ()
     at /usr/src/sys/amd64/amd64/exception.S:228
 #7  0xffffffff80940a79 in ipsec_process_done (m=0xfffffe00128b9d00,
     isr=0xfffffe00785d3b00) at /usr/src/sys/netipsec/ipsec_output.c:170
 #8  0xffffffff8094fc31 in esp_output_cb (crp=0xfffffe02055c4dc0)
     at /usr/src/sys/netipsec/xform_esp.c:1007
 #9  0xffffffff80968832 in crypto_done (crp=0xfffffe02055c4dc0)
     at /usr/src/sys/opencrypto/crypto.c:1156
 #10 0xffffffff8096c3e7 in swcr_process (dev=Variable "dev" is not available.
 )
     at /usr/src/sys/opencrypto/cryptosoft.c:1054
 #11 0xffffffff809696bb in crypto_invoke (cap=0xfffffe00051ed600,
     crp=0xfffffe02055c4dc0, hint=0) at cryptodev_if.h:53
 #12 0xffffffff8096a4eb in crypto_dispatch (crp=0xfffffe02055c4dc0)
     at /usr/src/sys/opencrypto/crypto.c:806
 #13 0xffffffff80950282 in esp_output (m=0x80, isr=0xfffffe00785d3b00, mp=Variable "mp" is not available.
 )
     at /usr/src/sys/netipsec/xform_esp.c:907
 #14 0xffffffff80940d98 in ipsec4_process_packet (m=0xfffffe00128b9d00,
     isr=0xfffffe00785d3b00, flags=Variable "flags" is not available.
 )
     at /usr/src/sys/netipsec/ipsec_output.c:580
 #15 0xffffffff808822e3 in ip_ipsec_output (m=0xffffff800026b8a8, inp=Variable "inp" is not available.
 )
     at /usr/src/sys/netinet/ip_ipsec.c:353
 #16 0xffffffff80883ee1 in ip_output (m=0xfffffe00128b9d00, opt=Variable "opt" is not available.
 )
     at /usr/src/sys/netinet/ip_output.c:480
 #17 0xffffffff8087f0e9 in icmp_reflect (m=0xfffffe00128b9d00)
     at /usr/src/sys/netinet/ip_icmp.c:886
 #18 0xffffffff8087f677 in icmp_input (m=0xfffffe00128b9d00, off=20)
     at /usr/src/sys/netinet/ip_icmp.c:571
 #19 0xffffffff80881bcd in ip_input (m=0xfffffe00128b9d00)
     at /usr/src/sys/netinet/ip_input.c:760
 #20 0xffffffff808259dd in swi_net (arg=Variable "arg" is not available.
 ) at /usr/src/sys/net/netisr.c:806
 #21 0xffffffff807388c4 in intr_event_execute_handlers (p=Variable "p" is not available.
 )
     at /usr/src/sys/kern/kern_intr.c:1257
 #22 0xffffffff8073a084 in ithread_loop (arg=0xfffffe00051c4320)
     at /usr/src/sys/kern/kern_intr.c:1270
 #23 0xffffffff80735aaf in fork_exit (
     callout=0xffffffff80739fe0 <ithread_loop>, arg=0xfffffe00051c4320,
     frame=0xffffff800026bc50) at /usr/src/sys/kern/kern_fork.c:995
 #24 0xffffffff80a734be in fork_trampoline ()
     at /usr/src/sys/amd64/amd64/exception.S:602
 #25 0x0000000000000000 in ?? ()
 #26 0x0000000000000000 in ?? ()
 #27 0x0000000000000001 in ?? ()
 #28 0x0000000000000000 in ?? ()
 #29 0x0000000000000000 in ?? ()
 #30 0x0000000000000000 in ?? ()
 #31 0x0000000000000000 in ?? ()
 #32 0x0000000000000000 in ?? ()
 #33 0x0000000000000000 in ?? ()
 #34 0x0000000000000000 in ?? ()
 #35 0x0000000000000000 in ?? ()
 #36 0x0000000000000000 in ?? ()
 #37 0x0000000000000000 in ?? ()
 #38 0x0000000000000000 in ?? ()
 #39 0x0000000000000000 in ?? ()
 #40 0x0000000000000000 in ?? ()
 #41 0x0000000000000000 in ?? ()
 #42 0x0000000000000000 in ?? ()
 #43 0x0000000000000000 in ?? ()
 #44 0x0000000000000000 in ?? ()
 #45 0x0000000000000000 in ?? ()
 #46 0x0000000000000000 in ?? ()
 #47 0x0000000000000000 in ?? ()
 #48 0x0000000000000000 in ?? ()
 #49 0xffffffff8104e340 in affinity ()
 #50 0x0000000000000000 in ?? ()
 #51 0x0000000000000000 in ?? ()
 #52 0xfffffe00051df000 in ?? ()
 #53 0xffffff800026aef0 in ?? ()
 #54 0xffffff800026ae98 in ?? ()
 #55 0xfffffe00051c9000 in ?? ()
 #56 0xffffffff8078a782 in sched_switch (td=0xffffffff80739fe0,
     newtd=0xfffffe00051c4320, flags=Variable "flags" is not available.
 ) at /usr/src/sys/kern/sched_ule.c:1848
 Previous frame inner to this frame (corrupt stack?)
 (kgdb)
 

From: "Eugene M. Zheganin" <emz@norma.perm.ru>
To: bug-followup@FreeBSD.org, eugene@zhegan.in
Cc:  
Subject: Re: kern/164400: [ipsec] immediate crash after the start of ipsec
 processing
Date: Tue, 22 May 2012 00:46:00 +0600

 Rolling back this commit solves the problem:
 
 http://svnweb.freebsd.org/base/releng/9.0/sys/netipsec/ipsec_output.c?sortdir=down&r1=221128&r2=221129&

From: "Bjoern A. Zeeb" <bz@FreeBSD.org>
To: bug-followup@FreeBSD.org, eugene@zhegan.in, 
    "Andrew A. Khlebutin" <ak@dartit.ru>
Cc:  
Subject: Re: kern/164400: [ipsec] immediate crash after the start of ipsec
 processing
Date: Thu, 24 May 2012 21:50:38 +0000 (UTC)

 Hi,
 Cc:ing other reports in the PR
 
 so given ESP is doing all AH gives you, can you confirm that not
 chaining ESP and AH but just ESP fixes the problem?
 
 Also note that AH is questioned to become obsolete for ESP null
 encryption.  Not sure we are there yet.
 
 I see the problem and I'll try to fix it anyway as a differnt chain
 might as well trigger it.
 
 /bz
 
 -- 
 Bjoern A. Zeeb                                 You have to have visions!
           Stop bit received. Insert coin for new address family.
Responsible-Changed-From-To: freebsd-net->bz 
Responsible-Changed-By: bz 
Responsible-Changed-When: Thu May 24 23:40:20 UTC 2012 
Responsible-Changed-Why:  
Whoops, it wasn't assigned to me yet.  I broke it, I'll fix it 
though it has taken me a while to get to this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=164400 
State-Changed-From-To: open->feedback 
State-Changed-By: bz 
State-Changed-When: Sun Jul 8 20:03:17 UTC 2012 
State-Changed-Why:  
Patch proposed (apart from that AH and ESP makes not much 
sense but could be ipcomp + esp as well). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=164400 

From: "Bjoern A. Zeeb" <bz@FreeBSD.org>
To: bug-followup@FreeBSD.org, eugene@zhegan.in, 
    "Andrew A. Khlebutin" <ak@dartit.ru>
Cc:  
Subject: Re: kern/164400: [ipsec] immediate crash after the start of ipsec
 processing
Date: Sun, 8 Jul 2012 20:02:53 +0000 (UTC)

 Hey,
 
 can you try this simple patch and report back?  I'd try to get it into
 HEAD and the upcoming 9.1-RELEASE if it's good.
 
 http://people.freebsd.org/~bz/20120708-02-pr164400.diff
 
 Index: sys/netipsec/ipsec_output.c
 ===================================================================
 --- sys/netipsec/ipsec_output.c	(revision 236577)
 +++ sys/netipsec/ipsec_output.c	(working copy)
 @@ -165,8 +165,7 @@ ipsec_process_done(struct mbuf *m, struct ipsecreq
   	 */
   	if (isr->next) {
   		V_ipsec4stat.ips_out_bundlesa++;
 -		sav = isr->next->sav;
 -		saidx = &sav->sah->saidx;
 +		/* XXX-BZ currently only support same AF bundles. */
   		switch (saidx->dst.sa.sa_family) {
   #ifdef INET
   		case AF_INET:
 
 
 -- 
 Bjoern A. Zeeb                                 You have to have visions!
           Stop bit received. Insert coin for new address family.

From: "Eugene M. Zheganin" <emz@norma.perm.ru>
To: bug-followup@FreeBSD.org, eugene@zhegan.in
Cc:  
Subject: Re: kern/164400: [ipsec] immediate crash after the start of ipsec
 processing
Date: Sat, 21 Jul 2012 01:42:11 +0600

 Sorry it took so long, but I got stuck with this new shiny default 
 GEOM_RAID option in the GENERIC. :P
 
 Anyway with this new patch it works just fine, like always.
 
 FreeBSD zombie.hq.norma.perm.ru 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 
 r238525: Tue Jul 17 10:09:03 YEKT 2012 
 emz@necromancer:/usr/obj/usr/src/sys/ZOMBIE  i386
 
 Tried it with the full ah + esp encryption.
 Thanks.
 (Did I miss the time for this to be commited in 9.1 ?)
State-Changed-From-To: feedback->patched 
State-Changed-By: bz 
State-Changed-When: Sun Jul 22 17:46:32 UTC 2012 
State-Changed-Why:  
Committed to HEAD as r238700.  Will try to MFC for 9.1-R. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=164400 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/164400: commit references a PR
Date: Sun, 22 Jul 2012 17:46:17 +0000 (UTC)

 Author: bz
 Date: Sun Jul 22 17:46:05 2012
 New Revision: 238700
 URL: http://svn.freebsd.org/changeset/base/238700
 
 Log:
   Fix a bug introduced in r221129 that leads to a panic wen using bundled
   SAs.  For now allow same address family bundles.  While discovered with
   ESP and AH, which does not make a lot of sense, IPcomp could be a possible
   problematic candidate.
   
   PR:		kern/164400
   MFC after:	3 days
 
 Modified:
   head/sys/netipsec/ipsec_output.c
 
 Modified: head/sys/netipsec/ipsec_output.c
 ==============================================================================
 --- head/sys/netipsec/ipsec_output.c	Sun Jul 22 17:31:36 2012	(r238699)
 +++ head/sys/netipsec/ipsec_output.c	Sun Jul 22 17:46:05 2012	(r238700)
 @@ -165,8 +165,7 @@ ipsec_process_done(struct mbuf *m, struc
  	 */
  	if (isr->next) {
  		V_ipsec4stat.ips_out_bundlesa++;
 -		sav = isr->next->sav;
 -		saidx = &sav->sah->saidx;
 +		/* XXX-BZ currently only support same AF bundles. */
  		switch (saidx->dst.sa.sa_family) {
  #ifdef INET
  		case AF_INET:
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/164400: commit references a PR
Date: Wed, 25 Jul 2012 19:18:42 +0000 (UTC)

 Author: bz
 Date: Wed Jul 25 19:18:28 2012
 New Revision: 238777
 URL: http://svn.freebsd.org/changeset/base/238777
 
 Log:
   MFC r238700:
   
     Fix a bug introduced in r221129 that leads to a panic when using bundled
     SAs.  For now allow same address family bundles.
   
   PR:		kern/164400
   Approved by:	re (kib)
 
 Modified:
   stable/9/sys/netipsec/ipsec_output.c
 Directory Properties:
   stable/9/sys/   (props changed)
 
 Modified: stable/9/sys/netipsec/ipsec_output.c
 ==============================================================================
 --- stable/9/sys/netipsec/ipsec_output.c	Wed Jul 25 17:49:01 2012	(r238776)
 +++ stable/9/sys/netipsec/ipsec_output.c	Wed Jul 25 19:18:28 2012	(r238777)
 @@ -165,8 +165,7 @@ ipsec_process_done(struct mbuf *m, struc
  	 */
  	if (isr->next) {
  		V_ipsec4stat.ips_out_bundlesa++;
 -		sav = isr->next->sav;
 -		saidx = &sav->sah->saidx;
 +		/* XXX-BZ currently only support same AF bundles. */
  		switch (saidx->dst.sa.sa_family) {
  #ifdef INET
  		case AF_INET:
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: patched->closed 
State-Changed-By: bz 
State-Changed-When: Wed Jul 25 19:30:31 UTC 2012 
State-Changed-Why:  
Thanks a lot for reporting and testing!  MFCed to stable/9 for 9.1-R. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=164400 
>Unformatted:
