linux-stable.git/crypto, branch v3.18.28

crypto: user - lock crypto_alg_list on alg dump

2016-03-02T20:18:58+00:00

[ Upstream commit 63e41ebc6630f39422d87f8a4bade1e793f37a01 ]

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:[]  [] 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]  [] crypto_report_alg+0xc0/0x3e0
[ 3482.075639]  [] ? __alloc_skb+0x16f/0x300
[ 3482.075639]  [] crypto_dump_report+0x6a/0x90
[ 3482.075639]  [] netlink_dump+0x147/0x2e0
[ 3482.075639]  [] __netlink_dump_start+0x159/0x190
[ 3482.075639]  [] crypto_user_rcv_msg+0xc3/0x130
[ 3482.075639]  [] ? crypto_report_alg+0x3e0/0x3e0
[ 3482.075639]  [] ? alg_test_crc32c+0x120/0x120
[ 3482.075639]  [] ? __netlink_lookup+0xd5/0x120
[ 3482.075639]  [] ? crypto_add_alg+0x1d0/0x1d0
[ 3482.075639]  [] netlink_rcv_skb+0xe1/0x130
[ 3482.075639]  [] crypto_netlink_rcv+0x28/0x40
[ 3482.075639]  [] netlink_unicast+0x108/0x180
[ 3482.075639]  [] netlink_sendmsg+0x541/0x770
[ 3482.075639]  [] sock_sendmsg+0x21/0x40
[ 3482.075639]  [] SyS_sendto+0xf3/0x130
[ 3482.075639]  [] ? bad_area_nosemaphore+0x13/0x20
[ 3482.075639]  [] ? __do_page_fault+0x80/0x3a0
[ 3482.075639]  [] 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 <0f> b6 16 80 fa 01 88 11 48 83 de ff 48 83 c1 01 4c 39 c1 75 eb
[ 3482.075639] RIP  [] 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 > /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.

Cc: stable@vger.kernel.org
Signed-off-by: Mathias Krause 
Cc: Steffen Klassert 
Cc: PaX Team 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

X.509: Don't strip leading 00's from key ID when constructing key description

2016-02-15T20:42:42+00:00

[ Upstream commit e7c87bef7de2417b219d4dbfe8d33a0098a8df54 ]

Don't strip leading zeros from the crypto key ID when using it to construct
the struct key description as the signature in kernels up to and including
4.2 matched this aspect of the key.  This means that 1 in 256 keys won't
actually match if their key ID begins with 00.

The key ID is stored in the module signature as binary and so must be
converted to text in order to invoke request_key() - but it isn't stripped
at this point.

Something like this is likely to be observed in dmesg when the key is loaded:

[    1.572423] Loaded X.509 cert 'Build time autogenerated kernel
    key: 62a7c3d2da278be024da4af8652c071f3fea33'

followed by this when we try and use it:

  [    1.646153] Request for unknown module key 'Build time autogenerated
    kernel key: 0062a7c3d2da278be024da4af8652c071f3fea33' err -11

The 'Loaded' line should show an extra '00' on the front of the hex string.

This problem should not affect 4.3-rc1 and onwards because there the key
should be matched on one of its auxiliary identities rather than the key
struct's description string.

Reported-by: Arjan van de Ven 
Reported-by: Andy Whitcroft 
Signed-off-by: David Howells 
Signed-off-by: Sasha Levin

crypto: algif_hash - wait for crypto_ahash_init() to complete

2016-02-15T20:42:36+00:00

[ Upstream commit fe09786178f9df713a4b2dd6b93c0a722346bf5e ]

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

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

crypto: shash - Fix has_key setting

2016-02-15T20:42:35+00:00

[ Upstream commit 00420a65fa2beb3206090ead86942484df2275f3 ]

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")
Cc: stable@vger.kernel.org
Reported-by: Stephan Mueller 
Signed-off-by: Herbert Xu 
Tested-by: Stephan Mueller 
Signed-off-by: Sasha Levin

crypto: crc32c - Fix crc32c soft dependency

2016-02-10T03:57:34+00:00

[ Upstream commit fd7f6727102a1ccf6b4c1dfcc631f9b546526b26 ]

I don't think it makes sense for a module to have a soft dependency
on itself. This seems quite cyclic by nature and I can't see what
purpose it could serve.

OTOH libcrc32c calls crypto_alloc_shash("crc32c", 0, 0) so it pretty
much assumes that some incarnation of the "crc32c" hash algorithm has
been loaded. Therefore it makes sense to have the soft dependency
there (as crc-t10dif does.)

Cc: stable@vger.kernel.org
Cc: Tim Chen 
Cc: "David S. Miller" 
Signed-off-by: Jean Delvare 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: algif_hash - Fix race condition in hash_check_key

2016-02-10T03:57:34+00:00

[ Upstream commit ad46d7e33219218605ea619e32553daf4f346b9f ]

We need to lock the child socket in hash_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

crypto: af_alg - Forbid bind(2) when nokey child sockets are present

2016-02-10T03:57:33+00:00

[ Upstream commit a6a48c565f6f112c6983e2a02b1602189ed6e26e ]

This patch forbids the calling of bind(2) when there are child
sockets created by accept(2) in existence, even if they are created
on the nokey path.

This is needed as those child sockets have references to the tfm
object which bind(2) will destroy.

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

crypto: algif_hash - Remove custom release parent function

2016-02-10T03:57:33+00:00

[ Upstream commit f1d84af1835846a5a2b827382c5848faf2bb0e75 ]

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

crypto: af_alg - Allow af_af_alg_release_parent to be called on nokey path

2016-02-10T03:57:33+00:00

[ Upstream commit 6a935170a980024dd29199e9dbb5c4da4767a1b9 ]

This patch allows af_alg_release_parent to be called even for
nokey sockets.

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

crypto: algif_hash - Require setkey before accept(2)

2016-02-10T03:57:32+00:00

[ Upstream commit 6de62f15b581f920ade22d758f4c338311c2f0d4 ]

Hash implementations that require a key may crash if you use
them without setting a key.  This patch adds the necessary checks
so that if you do attempt to use them without a key that we return
-ENOKEY instead of proceeding.

This patch also 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