13 Jan, 2015
1 commit
-
Commit 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
changed the automatic module loading when requesting crypto algorithms
to prefix all module requests with "crypto-". This requires all crypto
modules to have a crypto specific module alias even if their file name
would otherwise match the requested crypto algorithm.Even though commit 5d26a105b5a7 added those aliases for a vast amount of
modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
annotations to those files to make them get loaded automatically, again.
This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
with kernels v3.18 and below.Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
won't work for crypto modules any more.Fixes: 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
Cc: Kees Cook
Signed-off-by: Mathias Krause
Signed-off-by: Herbert Xu
24 Nov, 2014
1 commit
-
This prefixes all crypto module loading with "crypto-" so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:https://lkml.org/lkml/2013/3/4/70
Signed-off-by: Kees Cook
Signed-off-by: Herbert Xu
01 Aug, 2012
1 commit
-
Initialization of cra_list is currently mixed, most ciphers initialize this
field and most shashes do not. Initialization however is not needed at all
since cra_list is initialized/overwritten in __crypto_register_alg() with
list_add(). Therefore perform cleanup to remove all unneeded initializations
of this field in 'crypto/'.Signed-off-by: Jussi Kivilinna
Signed-off-by: Herbert Xu
21 Oct, 2011
1 commit
-
The ghash_update function passes a pointer to gf128mul_4k_lle which will
be NULL if ghash_setkey is not called or if the most recent call to
ghash_setkey failed to allocate memory. This causes an oops. Fix this
up by returning an error code in the null case.This is trivially triggered from unprivileged userspace through the
AF_ALG interface by simply writing to the socket without setting a key.The ghash_final function has a similar issue, but triggering it requires
a memory allocation failure in ghash_setkey _after_ at least one
successful call to ghash_update.BUG: unable to handle kernel NULL pointer dereference at 00000670
IP: [] gf128mul_4k_lle+0x23/0x60 [gf128mul]
*pde = 00000000
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: ghash_generic gf128mul algif_hash af_alg nfs lockd nfs_acl sunrpc bridge ipv6 stp llcPid: 1502, comm: hashatron Tainted: G W 3.1.0-rc9-00085-ge9308cf #32 Bochs Bochs
EIP: 0060:[] EFLAGS: 00000202 CPU: 0
EIP is at gf128mul_4k_lle+0x23/0x60 [gf128mul]
EAX: d69db1f0 EBX: d6b8ddac ECX: 00000004 EDX: 00000000
ESI: 00000670 EDI: d6b8ddac EBP: d6b8ddc8 ESP: d6b8dda4
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process hashatron (pid: 1502, ti=d6b8c000 task=d6810000 task.ti=d6b8c000)
Stack:
00000000 d69db1f0 00000163 00000000 d6b8ddc8 c101a520 d69db1f0 d52aa000
00000ff0 d6b8dde8 d88d310f d6b8a3f8 d52aa000 00001000 d88d502c d6b8ddfc
00001000 d6b8ddf4 c11676ed d69db1e8 d6b8de24 c11679ad d52aa000 00000000
Call Trace:
[] ? kmap_atomic_prot+0x37/0xa6
[] ghash_update+0x85/0xbe [ghash_generic]
[] crypto_shash_update+0x18/0x1b
[] shash_ahash_update+0x22/0x36
[] shash_async_update+0xb/0xd
[] hash_sendpage+0xba/0xf2 [algif_hash]
[] kernel_sendpage+0x39/0x4e
[] ? 0xd88cdfff
[] sock_sendpage+0x37/0x3e
[] ? kernel_sendpage+0x4e/0x4e
[] pipe_to_sendpage+0x56/0x61
[] splice_from_pipe_feed+0x58/0xcd
[] ? splice_from_pipe_begin+0x10/0x10
[] __splice_from_pipe+0x36/0x55
[] ? splice_from_pipe_begin+0x10/0x10
[] splice_from_pipe+0x51/0x64
[] ? default_file_splice_write+0x2c/0x2c
[] generic_splice_sendpage+0x13/0x15
[] ? splice_from_pipe_begin+0x10/0x10
[] do_splice_from+0x5d/0x67
[] sys_splice+0x2bf/0x363
[] ? sysenter_exit+0xf/0x16
[] ? trace_hardirqs_on_caller+0x10e/0x13f
[] sysenter_do_call+0x12/0x32
Code: 83 c4 0c 5b 5e 5f c9 c3 55 b9 04 00 00 00 89 e5 57 8d 7d e4 56 53 8d 5d e4 83 ec 18 89 45 e0 89 55 dc 0f b6 70 0f c1 e6 04 01 d6 a5 be 0f 00 00 00 4e 89 d8 e8 48 ff ff ff 8b 45 e0 89 da 0f
EIP: [] gf128mul_4k_lle+0x23/0x60 [gf128mul] SS:ESP 0068:d6b8dda4
CR2: 0000000000000670
---[ end trace 4eaa2a86a8e2da24 ]---
note: hashatron[1502] exited with preempt_count 1
BUG: scheduling while atomic: hashatron/1502/0x10000002
INFO: lockdep is turned off.
[...]Signed-off-by: Nick Bowler
Cc: stable@kernel.org [2.6.37+]
Signed-off-by: Herbert Xu
06 Aug, 2009
1 commit
-
GHASH is implemented as a shash algorithm. The actual implementation
is copied from gcm.c. This makes it possible to add
architecture/hardware accelerated GHASH implementation.Signed-off-by: Huang Ying
Signed-off-by: Herbert Xu