30 Oct, 2013
1 commit
-
Previously we would use eseqiv on all async ciphers in all cases,
and sync ciphers if we have more than one CPU. This meant that
chainiv is only used in the case of sync ciphers on a UP machine.As chainiv may aid attackers by making the IV predictable, even
though this risk itself is small, the above usage pattern causes
it to further leak information about the host.This patch addresses these issues by using eseqiv even if we're
on a UP machine.Signed-off-by: Herbert Xu
Acked-by: Steffen Klassert
Acked-by: David S. Miller
19 Feb, 2013
1 commit
-
Three errors resulting in kernel memory disclosure:
1/ The structures used for the netlink based crypto algorithm report API
are located on the stack. As snprintf() does not fill the remainder of
the buffer with null bytes, those stack bytes will be disclosed to users
of the API. Switch to strncpy() to fix this.2/ crypto_report_one() does not initialize all field of struct
crypto_user_alg. Fix this to fix the heap info leak.3/ For the module name we should copy only as many bytes as
module_name() returns -- not as much as the destination buffer could
hold. But the current code does not and therefore copies random data
from behind the end of the module name, as the module name is always
shorter than CRYPTO_MAX_ALG_NAME.Also switch to use strncpy() to copy the algorithm's name and
driver_name. They are strings, after all.Signed-off-by: Mathias Krause
Cc: Steffen Klassert
Signed-off-by: Herbert Xu
11 Apr, 2012
1 commit
02 Apr, 2012
1 commit
-
These macros contain a hidden goto, and are thus extremely error
prone and make code hard to audit.Signed-off-by: David S. Miller
29 Mar, 2012
1 commit
-
We lookup algorithms with crypto_alg_mod_lookup() when instantiating via
crypto_add_alg(). However, algorithms that are wrapped by an IV genearator
(e.g. aead or genicv type algorithms) need special care. The userspace
process hangs until it gets a timeout when we use crypto_alg_mod_lookup()
to lookup these algorithms. So export the lookup functions for these
algorithms and use them in crypto_add_alg().Signed-off-by: Steffen Klassert
Signed-off-by: Herbert Xu
11 Nov, 2011
1 commit
-
The report functions use NLA_PUT so we need to ensure that NET
is enabled.Reported-by: Luis Henriques
Signed-off-by: Herbert Xu
21 Oct, 2011
2 commits
-
Signed-off-by: Steffen Klassert
Signed-off-by: Herbert Xu -
Signed-off-by: Steffen Klassert
Signed-off-by: Herbert Xu
29 Jan, 2011
1 commit
-
Signed-off-by: Davidlohr Bueso
Acked-by: David S. Miller
Signed-off-by: Herbert Xu
23 Jun, 2010
1 commit
-
Stanse found a potential NULL dereference in ablkcipher_next_slow.
Even though kmalloc fails, its retval is dereferenced later. Return
from that function properly earlier.Signed-off-by: Jiri Slaby
Acked-by: David S. Miller
Signed-off-by: Herbert Xu
19 May, 2010
1 commit
-
These are akin to the blkcipher_walk helpers.
The main differences in the async variant are:
1) Only physical walking is supported. We can't hold on to
kmap mappings across the async operation to support virtual
ablkcipher_walk operations anyways.2) Bounce buffers used for async more need to be persistent and
freed at a later point in time when the async op completes.
Therefore we maintain a list of writeback buffers and require
that the ablkcipher_walk user call the 'complete' operation
so we can copy the bounce buffers out to the real buffers and
free up the bounce buffer chunks.These interfaces will be used by the new Niagara2 crypto driver.
Signed-off-by: David S. Miller
Signed-off-by: Herbert Xu
16 Feb, 2010
1 commit
-
Signed-off-by: Richard Hartmann
Signed-off-by: Herbert Xu
14 Aug, 2009
1 commit
-
Recently we switched to using eseqiv on SMP machines in preference
over chainiv. However, eseqiv does not support stream ciphers so
they should still default to chainiv.This patch applies the same check as done by eseqiv to weed out
the stream ciphers. In particular, all algorithms where the IV
size is not equal to the block size will now default to chainiv.Signed-off-by: Herbert Xu
25 Jun, 2009
2 commits
-
As it stands we use chainiv for sync algorithms and eseqiv for
async algorithms. However, when there is more than one CPU
chainiv forces all processing to be serialised which is usually
not what you want. Also, the added overhead of eseqiv isn't that
great.Therefore this patch changes the default sync geniv on SMP machines
to eseqiv. For the odd situation where the overhead is unacceptable
then chainiv is still available as an option.Note that on UP machines chainiv is still preferred over eseqiv
for sync algorithms.Signed-off-by: Herbert Xu
-
When a sync givcipher algorithm is requested, if an async version
of the same algorithm already exists, then we will loop forever
without ever constructing the sync version based on a blkcipher.This is because we did not include the requested type/mask when
getting a larval for the geniv algorithm that is to be constructed.Signed-off-by: Herbert Xu