+++ This bug was initially created as a clone of Bug #709517 +++

Description of problem:
It looks as though intel_aes_decrypt_cbc_256() doesn't work right when the input and output buffers are the same, though this appears to be something that PK11_CipherOp (which eventually calls this function, on processors that support it) is expected to be able to handle.

Version-Release number of selected component (if applicable):
nss-softokn-freebl-3.12.10-1.fc15.x86_64

How reproducible:
Always, provided you're on a 64-bit processor with native AES instruction support (the "flags:" line in /proc/cpuinfo will include "aes").  I've tested this on an i5 processor and also had it checked on an i7.

Steps to Reproduce:
1. Run reproducer with the "-i" flag, which will cause it to use the same buffer for input and output and default to a 256-bit key.
  
Actual results:
"data mismatch"

Expected results:
"Encrypted/recovered 32 bytes."

Additional info:
While NSS itself doesn't seem to trigger this behavior, the nascent support for using NSS as the backend for krb5's libk5crypto does.

--- Additional comment from nalin on 2011-05-31 17:19:59 EDT ---

Created attachment 502120 [details]
test

Compile:
  gcc -o aest aest.c `pkg-config --cflags --libs nss`
Run:
  ./aest -i                          (uses in-place encryption, errors out)
  env NSS_DISABLE_HW_AES=1 ./aest -i (uses unoptimized implementation, no error)
  ./aest                             (doesn't do encryption in place, no error)