linux.git/crypto, branch v4.1.29

PKCS#7: pkcs7_validate_trust(): initialize the _trusted output argument

2016-07-11T03:06:57+00:00

[ Upstream commit e54358915d0a00399c11c2c23ae1be674cba188a ]

Despite what the DocBook comment to pkcs7_validate_trust() says, the
*_trusted argument is never set to false.

pkcs7_validate_trust() only positively sets *_trusted upon encountering
a trusted PKCS#7 SignedInfo block.

This is quite unfortunate since its callers, system_verify_data() for
example, depend on pkcs7_validate_trust() clearing *_trusted on non-trust.

Indeed, UBSAN splats when attempting to load the uninitialized local
variable 'trusted' from system_verify_data() in pkcs7_validate_trust():

  UBSAN: Undefined behaviour in crypto/asymmetric_keys/pkcs7_trust.c:194:14
  load of value 82 is not a valid value for type '_Bool'
  [...]
  Call Trace:
    [] dump_stack+0xbc/0x117
    [] ? _atomic_dec_and_lock+0x169/0x169
    [] ubsan_epilogue+0xd/0x4e
    [] __ubsan_handle_load_invalid_value+0x111/0x158
    [] ? val_to_string.constprop.12+0xcf/0xcf
    [] ? x509_request_asymmetric_key+0x114/0x370
    [] ? kfree+0x220/0x370
    [] ? public_key_verify_signature_2+0x32/0x50
    [] pkcs7_validate_trust+0x524/0x5f0
    [] system_verify_data+0xca/0x170
    [] ? top_trace_array+0x9b/0x9b
    [] ? __vfs_read+0x279/0x3d0
    [] mod_verify_sig+0x1ff/0x290
    [...]

The implication is that pkcs7_validate_trust() effectively grants trust
when it really shouldn't have.

Fix this by explicitly setting *_trusted to false at the very beginning
of pkcs7_validate_trust().

Cc: 
Signed-off-by: Nicolai Stange 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: public_key: select CRYPTO_AKCIPHER

2016-06-17T13:09:18+00:00

[ Upstream commit bad6a185b4d6f81d0ed2b6e4c16307969f160b95 ]

In some rare randconfig builds, we can end up with
ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER disabled,
which fails to link because of the reference to crypto_alloc_akcipher:

crypto/built-in.o: In function `public_key_verify_signature':
:(.text+0x110e4): undefined reference to `crypto_alloc_akcipher'

This adds a Kconfig 'select' statement to ensure the dependency
is always there.

Cc: 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: hash - Fix page length clamping in hash walk

2016-05-17T17:42:59+00:00

[ Upstream commit 13f4bb78cf6a312bbdec367ba3da044b09bf0e29 ]

The crypto hash walk code is broken when supplied with an offset
greater than or equal to PAGE_SIZE.  This patch fixes it by adjusting
walk->pg and walk->offset when this happens.

Cc: 
Reported-by: Steffen Klassert 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

X.509: Fix leap year handling again

2016-04-18T12:50:43+00:00

[ Upstream commit ac4cbedfdf55455b4c447f17f0fa027dbf02b2a6 ]

There are still a couple of minor issues in the X.509 leap year handling:

 (1) To avoid doing a modulus-by-400 in addition to a modulus-by-100 when
     determining whether the year is a leap year or not, I divided the year
     by 100 after doing the modulus-by-100, thereby letting the compiler do
     one instruction for both, and then did a modulus-by-4.

     Unfortunately, I then passed the now-modified year value to mktime64()
     to construct a time value.

     Since this isn't a fast path and since mktime64() does a bunch of
     divisions, just condense down to "% 400".  It's also easier to read.

 (2) The default month length for any February where the year doesn't
     divide by four exactly is obtained from the month_length[] array where
     the value is 29, not 28.

     This is fixed by altering the table.

Reported-by: Rudolf Polzer 
Signed-off-by: David Howells 
Acked-by: David Woodhouse 
Acked-by: Arnd Bergmann 
cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

PKCS#7: Improve and export the X.509 ASN.1 time object decoder

2016-04-18T12:50:43+00:00

[ Upstream commit fd19a3d195be23e8d9d0d66576b96ea25eea8323 ]

Make the X.509 ASN.1 time object decoder fill in a time64_t rather than a
struct tm to make comparison easier (unfortunately, this makes readable
display less easy) and export it so that it can be used by the PKCS#7 code
too.

Further, tighten up its parsing to reject invalid dates (eg. weird
characters, non-existent hour numbers) and unsupported dates (eg. timezones
other than 'Z' or dates earlier than 1970).

Signed-off-by: David Howells 
Reviewed-by: David Woodhouse 
Signed-off-by: Sasha Levin

X.509: Extract both parts of the AuthorityKeyIdentifier

2016-04-18T12:50:42+00:00

[ Upstream commit b92e6570a992c7d793a209db282f68159368201c ]

Extract both parts of the AuthorityKeyIdentifier, not just the keyIdentifier,
as the second part can be used to match X.509 certificates by issuer and
serialNumber.

Signed-off-by: David Howells 
Tested-by: Vivek Goyal 
Signed-off-by: Sasha Levin

Backport fix for crypto: algif_skcipher - Fix race condition in skcipher_check_key

2016-02-28T05:09:45+00:00

commit 1822793a523e5d5730b19cc21160ff1717421bc8 upstream.

We need to lock the child socket in skcipher_check_key as otherwise
two simultaneous calls can cause the parent socket to be freed.

Cc: stable@vger.kernel.org
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

Backport fix for crypto: algif_skcipher - Remove custom release parent function

2016-02-28T05:09:45+00:00

commit d7b65aee1e7b4c87922b0232eaba56a8a143a4a0 upstream.

This patch removes the custom release parent function as the
generic af_alg_release_parent now works for nokey sockets too.

Cc: stable@vger.kernel.org
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

Backport fix for crypto: algif_skcipher - Add nokey compatibility path

2016-02-28T05:09:44+00:00

commit a0fa2d037129a9849918a92d91b79ed6c7bd2818 upstream.

This patch adds a compatibility path to support old applications
that do acept(2) before setkey.

Cc: stable@vger.kernel.org
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

Backport fix for crypto: algif_skcipher - Require setkey before accept(2)

2016-02-28T05:09:44+00:00

commit dd504589577d8e8e70f51f997ad487a4cb6c026f upstream.

Some cipher implementations will crash if you try to use them
without calling setkey first.  This patch adds a check so that
the accept(2) call will fail with -ENOKEY if setkey hasn't been
done on the socket yet.

Cc: stable@vger.kernel.org
Reported-by: Dmitry Vyukov 
Signed-off-by: Herbert Xu 
Tested-by: Dmitry Vyukov 
[backported to 4.1 by Milan Broz ]

Signed-off-by: Sasha Levin