Bug 806384 - Kernel panic when using AES encryption for IPSec tunnels
Kernel panic when using AES encryption for IPSec tunnels
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
unspecified Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  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:
Last Closed: 2012-09-05 12:35:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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.


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