From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Description of problem: If you create an active outgoing ipsec connection to a remote server using openwan 2.3.1 everything appears to work fine. After adding some iptables rules to fix the routing of packets between the two networks a kernel panic occurs at the console and the machine hangs. /upv4/xfrm4_output.c:108 spin_lock /net/sfrm/xfrm_state.c:dfebba14 already locked by net/ipv4/sfrm4_output.c/108 Specifically it happens when the firewall rule -A RH-Firewall-1-INPUT -s 10.0.13.0/24 -j ACCEPT (10.0.13.0/24 being the remote internal network) is added to the stock firewall rules creatd by RHEL4. Version-Release number of selected component (if applicable): kernel-2.6.9-5.EL How reproducible: Always Steps to Reproduce: 1. Create a valid IPSEC connection to a remote network 2. Add a iptables rule that allows traffic to be routed to the remote network 3. wait 15 seconds Actual Results: Kernel panic. /upv4/xfrm4_output.c:108 spin_lock /net/sfrm/xfrm_state.c:dfebba14 already locked by net/ipv4/sfrm4_output.c/108 Expected Results: Proper routing Additional info: There seems to be an issue regarding this at http://lkml.org/lkml/2005/4/5/216 describing the same deadlock condition.
not a openswan issue, and also we have no openswan in RHEL4... reassigning to kernel
Created attachment 112998 [details] Fix for deadlock This backport of a 2.6.12-rcX patch will fix the problem.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-514.html