Bug 806384 - Kernel panic when using AES encryption for IPSec tunnels
Kernel panic when using AES encryption for IPSec tunnels
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
16
i686 Linux
unspecified Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-23 11:29 EDT by Artur
Modified: 2012-09-05 12:35 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-05 12:35:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
crash backtrace got from serial console (25.60 KB, text/plain)
2012-03-23 11:29 EDT, Artur
no flags Details
Test configuration (network, ipsec) (1.38 KB, application/x-compressed-tar)
2012-03-23 11:30 EDT, Artur
no flags Details
Boot messages (33.96 KB, text/plain)
2012-03-23 11:31 EDT, Artur
no flags Details
some hardware info (10.16 KB, text/plain)
2012-03-23 11:31 EDT, Artur
no flags Details

  None (edit)
Description Artur 2012-03-23 11:29:09 EDT
Created attachment 572312 [details]
crash backtrace got from serial console

Description of problem:

When AES (128 bit) is used for phase 2 in IPSec configuration, kernel crashes as soon as a first encrypted packed arrives from remote end. Prior to this, all SAs are succesfully established.
When 3des encryption is used, everything works fine.

Version-Release number of selected component (if applicable):

Several last 3.2.x kernel versions from official Fedora repositories were tested with the same result. The report is for latest available version, 3.3.0-4.fc16.i686.PAE

How reproducible:

I am able to reproduce it every time I try to set up IPSec tunnel according to configuration included in attachments.

Steps to Reproduce:
1. Install ipsec-tools on two systems (r1, r2)
2. configure and bring up network
3. Put configuration files in /etc/racoon (test configuration attached below)
3. setkey -f /etc/racoon/setkey.conf (on both machines)
4. service racoon start (on both machines)
5. ping LAN side of r2 from r1
6. r2 crashes
  
Actual results:

Kernel panic.

Expected results:

Working IPSec tunnel with AES encryption.

Additional info:

Hardware used: HP DL180 G5
Boot messages, backtrace, some system information and test configuration included as attachments.

The only similar report I was able to find in internet is here: http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg06449.html

The obvious difference between aes and other encryption algorithms is, that aes is compiled as a part of main kernel image, other encryption modules are compiled as ... modules.

I tried this also using Openswan's userspace tools with the same result.

Probably I won't be able to test this anymore on affected systems, they will be put in production environment in 2 days. I don't know yet, whether it happens also on different hardware.
Comment 1 Artur 2012-03-23 11:30:36 EDT
Created attachment 572313 [details]
Test configuration (network, ipsec)
Comment 2 Artur 2012-03-23 11:31:05 EDT
Created attachment 572314 [details]
Boot messages
Comment 3 Artur 2012-03-23 11:31:35 EDT
Created attachment 572315 [details]
some hardware info
Comment 4 Artur 2012-03-25 15:03:03 EDT
Found workaround: recompiling kernel with CONFIG_CRYPTO_AES_NI_INTEL turned off helps.
Comment 5 Josh Boyer 2012-09-05 12:35:17 EDT
This was a result of an unaligned access on 32-bit.  It was fixed in the 3.5-rc4 kernel, and backported to 3.4.3 as well.  F16 is on 3.4.9 at the moment, so this should be fixed.

See 
https://bugzilla.kernel.org/show_bug.cgi?id=43223

Note You need to log in before you can comment on or make changes to this bug.