<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/crypto, branch v4.4.10</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.10</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.10'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2016-04-20T06:41:52Z</updated>
<entry>
<title>PKCS#7: pkcs7_validate_trust(): initialize the _trusted output argument</title>
<updated>2016-04-20T06:41:52Z</updated>
<author>
<name>Nicolai Stange</name>
<email>nicstange@gmail.com</email>
</author>
<published>2016-03-20T22:23:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=19c1764a19cdb41afebc2e66d7a75a7064c0000f'/>
<id>urn:sha1:19c1764a19cdb41afebc2e66d7a75a7064c0000f</id>
<content type='text'>
commit e54358915d0a00399c11c2c23ae1be674cba188a upstream.

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:
    [&lt;ffffffff818c4d35&gt;] dump_stack+0xbc/0x117
    [&lt;ffffffff818c4c79&gt;] ? _atomic_dec_and_lock+0x169/0x169
    [&lt;ffffffff8194113b&gt;] ubsan_epilogue+0xd/0x4e
    [&lt;ffffffff819419fa&gt;] __ubsan_handle_load_invalid_value+0x111/0x158
    [&lt;ffffffff819418e9&gt;] ? val_to_string.constprop.12+0xcf/0xcf
    [&lt;ffffffff818334a4&gt;] ? x509_request_asymmetric_key+0x114/0x370
    [&lt;ffffffff814b83f0&gt;] ? kfree+0x220/0x370
    [&lt;ffffffff818312c2&gt;] ? public_key_verify_signature_2+0x32/0x50
    [&lt;ffffffff81835e04&gt;] pkcs7_validate_trust+0x524/0x5f0
    [&lt;ffffffff813c391a&gt;] system_verify_data+0xca/0x170
    [&lt;ffffffff813c3850&gt;] ? top_trace_array+0x9b/0x9b
    [&lt;ffffffff81510b29&gt;] ? __vfs_read+0x279/0x3d0
    [&lt;ffffffff8129372f&gt;] 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().

Signed-off-by: Nicolai Stange &lt;nicstange@gmail.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>X.509: Fix leap year handling again</title>
<updated>2016-04-12T16:08:46Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2016-02-24T14:37:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=499f9ff872f8792d3318b0bd5e6533bfe48abf0d'/>
<id>urn:sha1:499f9ff872f8792d3318b0bd5e6533bfe48abf0d</id>
<content type='text'>
commit ac4cbedfdf55455b4c447f17f0fa027dbf02b2a6 upstream.

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 &lt;rpolzer@google.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: keywrap - memzero the correct memory</title>
<updated>2016-04-12T16:08:45Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2016-01-30T14:38:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f69c1b51f6da629e6f03b336ffec8c31b56e6f8a'/>
<id>urn:sha1:f69c1b51f6da629e6f03b336ffec8c31b56e6f8a</id>
<content type='text'>
commit 2b8b28fd232233c22fb61009dd8b0587390d2875 upstream.

We're clearing the wrong memory.  The memory corruption is likely
harmless because we weren't going to use that stack memory again but not
zeroing is a potential information leak.

Fixes: e28facde3c39 ('crypto: keywrap - add key wrapping block chaining mode')
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Acked-by: Stephan Mueller &lt;smueller@chronox.de&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: algif_skcipher - Do not set MAY_BACKLOG on the async path</title>
<updated>2016-02-17T20:31:05Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2016-02-03T13:39:27Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=12426bd6b05f286fe252ddb69c4aea3209d01d5b'/>
<id>urn:sha1:12426bd6b05f286fe252ddb69c4aea3209d01d5b</id>
<content type='text'>
commit dad41997063723eaf5f77bc2015606a5a9bce320 upstream.

The async path cannot use MAY_BACKLOG because it is not meant to
block, which is what MAY_BACKLOG does.  On the other hand, both
the sync and async paths can make use of MAY_SLEEP.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: algif_skcipher - Do not dereference ctx without socket lock</title>
<updated>2016-02-17T20:31:05Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2016-02-03T13:39:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=66bca97f21762ba58ce3d6767b27f782c702ef65'/>
<id>urn:sha1:66bca97f21762ba58ce3d6767b27f782c702ef65</id>
<content type='text'>
commit 6454c2b83f719057069777132b13949e4c6b6350 upstream.

Any access to non-constant bits of the private context must be
done under the socket lock, in particular, this includes ctx-&gt;req.

This patch moves such accesses under the lock, and fetches the
tfm from the parent socket which is guaranteed to be constant,
rather than from ctx-&gt;req.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: algif_skcipher - Do not assume that req is unchanged</title>
<updated>2016-02-17T20:31:05Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2016-02-03T13:39:24Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3e597bb7c3be2c69c03a6af95d27d5ed16b7b882'/>
<id>urn:sha1:3e597bb7c3be2c69c03a6af95d27d5ed16b7b882</id>
<content type='text'>
commit ec69bbfb9902c32a5c1492f2b1b8ad032a66d724 upstream.

The async path in algif_skcipher assumes that the crypto completion
function will be called with the original request.  This is not
necessarily the case.  In fact there is no need for this anyway
since we already embed information into the request with struct
skcipher_async_req.

This patch adds a pointer to that struct and then passes it as
the data to the callback function.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Tested-by: Tadeusz Struk &lt;tadeusz.struk@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: user - lock crypto_alg_list on alg dump</title>
<updated>2016-02-17T20:31:04Z</updated>
<author>
<name>Mathias Krause</name>
<email>minipli@googlemail.com</email>
</author>
<published>2016-02-01T13:27:30Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cfeab1cf35bcd023bb5db62635eccf8e8def7527'/>
<id>urn:sha1:cfeab1cf35bcd023bb5db62635eccf8e8def7527</id>
<content type='text'>
commit 63e41ebc6630f39422d87f8a4bade1e793f37a01 upstream.

We miss to take the crypto_alg_sem semaphore when traversing the
crypto_alg_list for CRYPTO_MSG_GETALG dumps. This allows a race with
crypto_unregister_alg() removing algorithms from the list while we're
still traversing it, thereby leading to a use-after-free as show below:

[ 3482.071639] general protection fault: 0000 [#1] SMP
[ 3482.075639] Modules linked in: aes_x86_64 glue_helper lrw ablk_helper cryptd gf128mul ipv6 pcspkr serio_raw virtio_net microcode virtio_pci virtio_ring virtio sr_mod cdrom [last unloaded: aesni_intel]
[ 3482.075639] CPU: 1 PID: 11065 Comm: crconf Not tainted 4.3.4-grsec+ #126
[ 3482.075639] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 3482.075639] task: ffff88001cd41a40 ti: ffff88001cd422c8 task.ti: ffff88001cd422c8
[ 3482.075639] RIP: 0010:[&lt;ffffffff93722bd3&gt;]  [&lt;ffffffff93722bd3&gt;] strncpy+0x13/0x30
[ 3482.075639] RSP: 0018:ffff88001f713b60  EFLAGS: 00010202
[ 3482.075639] RAX: ffff88001f6c4430 RBX: ffff88001f6c43a0 RCX: ffff88001f6c4430
[ 3482.075639] RDX: 0000000000000040 RSI: fefefefefefeff16 RDI: ffff88001f6c4430
[ 3482.075639] RBP: ffff88001f713b60 R08: ffff88001f6c4470 R09: ffff88001f6c4480
[ 3482.075639] R10: 0000000000000002 R11: 0000000000000246 R12: ffff88001ce2aa28
[ 3482.075639] R13: ffff880000093700 R14: ffff88001f5e4bf8 R15: 0000000000003b20
[ 3482.075639] FS:  0000033826fa2700(0000) GS:ffff88001e900000(0000) knlGS:0000000000000000
[ 3482.075639] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3482.075639] CR2: ffffffffff600400 CR3: 00000000139ec000 CR4: 00000000001606f0
[ 3482.075639] Stack:
[ 3482.075639]  ffff88001f713bd8 ffffffff936ccd00 ffff88001e5c4200 ffff880000093700
[ 3482.075639]  ffff88001f713bd0 ffffffff938ef4bf 0000000000000000 0000000000003b20
[ 3482.075639]  ffff88001f5e4bf8 ffff88001f5e4848 0000000000000000 0000000000003b20
[ 3482.075639] Call Trace:
[ 3482.075639]  [&lt;ffffffff936ccd00&gt;] crypto_report_alg+0xc0/0x3e0
[ 3482.075639]  [&lt;ffffffff938ef4bf&gt;] ? __alloc_skb+0x16f/0x300
[ 3482.075639]  [&lt;ffffffff936cd08a&gt;] crypto_dump_report+0x6a/0x90
[ 3482.075639]  [&lt;ffffffff93935707&gt;] netlink_dump+0x147/0x2e0
[ 3482.075639]  [&lt;ffffffff93935f99&gt;] __netlink_dump_start+0x159/0x190
[ 3482.075639]  [&lt;ffffffff936ccb13&gt;] crypto_user_rcv_msg+0xc3/0x130
[ 3482.075639]  [&lt;ffffffff936cd020&gt;] ? crypto_report_alg+0x3e0/0x3e0
[ 3482.075639]  [&lt;ffffffff936cc4b0&gt;] ? alg_test_crc32c+0x120/0x120
[ 3482.075639]  [&lt;ffffffff93933145&gt;] ? __netlink_lookup+0xd5/0x120
[ 3482.075639]  [&lt;ffffffff936cca50&gt;] ? crypto_add_alg+0x1d0/0x1d0
[ 3482.075639]  [&lt;ffffffff93938141&gt;] netlink_rcv_skb+0xe1/0x130
[ 3482.075639]  [&lt;ffffffff936cc4f8&gt;] crypto_netlink_rcv+0x28/0x40
[ 3482.075639]  [&lt;ffffffff939375a8&gt;] netlink_unicast+0x108/0x180
[ 3482.075639]  [&lt;ffffffff93937c21&gt;] netlink_sendmsg+0x541/0x770
[ 3482.075639]  [&lt;ffffffff938e31e1&gt;] sock_sendmsg+0x21/0x40
[ 3482.075639]  [&lt;ffffffff938e4763&gt;] SyS_sendto+0xf3/0x130
[ 3482.075639]  [&lt;ffffffff93444203&gt;] ? bad_area_nosemaphore+0x13/0x20
[ 3482.075639]  [&lt;ffffffff93444470&gt;] ? __do_page_fault+0x80/0x3a0
[ 3482.075639]  [&lt;ffffffff939d80cb&gt;] entry_SYSCALL_64_fastpath+0x12/0x6e
[ 3482.075639] Code: 88 4a ff 75 ed 5d 48 0f ba 2c 24 3f c3 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 85 d2 48 89 f8 48 89 f9 4c 8d 04 17 48 89 e5 74 15 &lt;0f&gt; b6 16 80 fa 01 88 11 48 83 de ff 48 83 c1 01 4c 39 c1 75 eb
[ 3482.075639] RIP  [&lt;ffffffff93722bd3&gt;] strncpy+0x13/0x30

To trigger the race run the following loops simultaneously for a while:
  $ while : ; do modprobe aesni-intel; rmmod aesni-intel; done
  $ while : ; do crconf show all &gt; /dev/null; done

Fix the race by taking the crypto_alg_sem read lock, thereby preventing
crypto_unregister_alg() from modifying the algorithm list during the
dump.

This bug has been detected by the PaX memory sanitize feature.

Signed-off-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Cc: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
Cc: PaX Team &lt;pageexec@freemail.hu&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: algif_hash - wait for crypto_ahash_init() to complete</title>
<updated>2016-02-17T20:31:04Z</updated>
<author>
<name>Wang, Rui Y</name>
<email>rui.y.wang@intel.com</email>
</author>
<published>2016-01-27T09:08:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=792c6ff0d8ce1a3d1da9f7b657aa6a8017515216'/>
<id>urn:sha1:792c6ff0d8ce1a3d1da9f7b657aa6a8017515216</id>
<content type='text'>
commit fe09786178f9df713a4b2dd6b93c0a722346bf5e upstream.

hash_sendmsg/sendpage() need to wait for the completion
of crypto_ahash_init() otherwise it can cause panic.

Signed-off-by: Rui Wang &lt;rui.y.wang@intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: shash - Fix has_key setting</title>
<updated>2016-02-17T20:31:04Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2016-01-26T16:16:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6bb06a4fa1894533beaab22f0c657866b0e61b06'/>
<id>urn:sha1:6bb06a4fa1894533beaab22f0c657866b0e61b06</id>
<content type='text'>
commit 00420a65fa2beb3206090ead86942484df2275f3 upstream.

The has_key logic is wrong for shash algorithms as they always
have a setkey function.  So we should instead be testing against
shash_no_setkey.

Fixes: a5596d633278 ("crypto: hash - Add crypto_ahash_has_setkey")
Reported-by: Stephan Mueller &lt;smueller@chronox.de&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Tested-by: Stephan Mueller &lt;smueller@chronox.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: algif_skcipher - sendmsg SG marking is off by one</title>
<updated>2016-02-17T20:31:04Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2016-01-19T13:23:57Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3dd3e2544c48d55e975efca5f34b77dbbe8895c9'/>
<id>urn:sha1:3dd3e2544c48d55e975efca5f34b77dbbe8895c9</id>
<content type='text'>
commit 202736d99b7f29279db9da61587f11a08a04a9c6 upstream.

We mark the end of the SG list in sendmsg and sendpage and unmark
it on the next send call.  Unfortunately the unmarking in sendmsg
is off-by-one, leading to an SG list that is too short.

Fixes: 0f477b655a52 ("crypto: algif - Mark sgl end at the end of data")
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
