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

    Herbert Xu
     

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

    Mathias Krause
     

11 Apr, 2012

1 commit


02 Apr, 2012

1 commit


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

    Steffen Klassert
     

11 Nov, 2011

1 commit


21 Oct, 2011

2 commits


29 Jan, 2011

1 commit


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

    Jiri Slaby
     

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

    David S. Miller
     

16 Feb, 2010

1 commit


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

    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

    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

    Herbert Xu