- 08 Jan, 2015 1 commit
-
-
Rabin Vincent authored
commit 7e77bdeb upstream. If a request is backlogged, it's complete() handler will get called twice: once with -EINPROGRESS, and once with the final error code. af_alg's complete handler, unlike other users, does not handle the -EINPROGRESS but instead always completes the completion that recvmsg() is waiting on. This can lead to a return to user space while the request is still pending in the driver. If userspace closes the sockets before the requests are handled by the driver, this will lead to use-after-frees (and potential crashes) in the kernel due to the tfm having been freed. The crashes can be easily reproduced (for example) by reducing the max queue length in cryptod.c and running the following (from http://www.chronox.de/libkcapi.html ) on AES-NI capable hardware: $ while true; do kcapi -x 1 -e -c '__ecb-aes-aesni' \ -k 00000000000000000000000000000000 \ -p 00000000000000000000000000000000 >/dev/null & done Signed-off-by:
Rabin Vincent <rabin.vincent@axis.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 31 Jul, 2014 1 commit
-
-
Milan Broz authored
Th AF_ALG socket was missing a security label (e.g. SELinux) which means that socket was in "unlabeled" state. This was recently demonstrated in the cryptsetup package (cryptsetup v1.6.5 and later.) See https://bugzilla.redhat.com/show_bug.cgi?id=1115120 This patch clones the sock's label from the parent sock and resolves the issue (similar to AF_BLUETOOTH protocol family). Cc: stable@vger.kernel.org Signed-off-by:
Milan Broz <gmazyland@gmail.com> Acked-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 15 Nov, 2013 1 commit
-
-
Wolfram Sang authored
Use this new function to make code more comprehensible, since we are reinitialzing the completion, not initializing. [akpm@linux-foundation.org: linux-next resyncs] Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13) Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 26 Jul, 2011 1 commit
-
-
Arun Sharma authored
This allows us to move duplicated code in <asm/atomic.h> (atomic_inc_not_zero() for now) to <linux/atomic.h> Signed-off-by:
Arun Sharma <asharma@fb.com> Reviewed-by:
Eric Dumazet <eric.dumazet@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: David Miller <davem@davemloft.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Acked-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 21 Dec, 2010 1 commit
-
-
Randy Dunlap authored
Change data type to fix warning: crypto/af_alg.c:35: warning: initialization from incompatible pointer type Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 08 Dec, 2010 1 commit
-
-
Miloslav Trmač authored
Signed-off-by:
Miloslav Trmač <mitr@redhat.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 19 Nov, 2010 1 commit
-
-
Herbert Xu authored
This patch creates the backbone of the user-space interface for the Crypto API, through a new socket family AF_ALG. Each session corresponds to one or more connections obtained from that socket. The number depends on the number of inputs/outputs of that particular type of operation. For most types there will be a s ingle connection/file descriptor that is used for both input and output. AEAD is one of the few that require two inputs. Each algorithm type will provide its own implementation that plugs into af_alg. They're keyed using a string such as "skcipher" or "hash". IOW this patch only contains the boring bits that is required to hold everything together. Thakns to Miloslav Trmac for reviewing this and contributing fixes and improvements. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Acked-by:
David S. Miller <davem@davemloft.net> Tested-by:
Martin Willi <martin@strongswan.org>
-