Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1316605 > unrolled thread
| Started by | Sasha Levin <sasha.levin@oracle.com> |
|---|---|
| First post | 2016-01-25 13:20 +0100 |
| Last post | 2016-01-26 15:50 +0100 |
| Articles | 6 — 2 participants |
Back to article view | Back to linux.kernel
crypto: algif_hash: creating 0 sized array in hash_accept Sasha Levin <sasha.levin@oracle.com> - 2016-01-25 13:20 +0100
Re: crypto: algif_hash: creating 0 sized array in hash_accept Herbert Xu <herbert@gondor.apana.org.au> - 2016-01-25 15:00 +0100
Re: crypto: algif_hash: creating 0 sized array in hash_accept Sasha Levin <sasha.levin@oracle.com> - 2016-01-26 14:30 +0100
Re: crypto: algif_hash: creating 0 sized array in hash_accept Herbert Xu <herbert@gondor.apana.org.au> - 2016-01-26 15:10 +0100
Re: crypto: algif_hash: creating 0 sized array in hash_accept Sasha Levin <sasha.levin@oracle.com> - 2016-01-26 15:40 +0100
Re: crypto: algif_hash: creating 0 sized array in hash_accept Herbert Xu <herbert@gondor.apana.org.au> - 2016-01-26 15:50 +0100
| From | Sasha Levin <sasha.levin@oracle.com> |
|---|---|
| Date | 2016-01-25 13:20 +0100 |
| Subject | crypto: algif_hash: creating 0 sized array in hash_accept |
| Message-ID | <qUOhH-3K1-3@gated-at.bofh.it> |
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next kernel
I've hit:
[ 828.386074] UBSAN: Undefined behaviour in crypto/algif_hash.c:185:7
[ 828.386811] variable length array bound value 0 <= 0
[ 828.387606] CPU: 1 PID: 17792 Comm: trinity-c313 Not tainted 4.4.0-next-20160122-sasha-00019-gd2a2eb4-dirty #2819
[ 828.388957] 1ffff10038e06f65 0000000087690421 ffff8801c7037ba8 ffffffffa34474f1
[ 828.394655] 0000000041b58ab3 ffffffffaf84c518 ffffffffa3447426 ffff8801c7037b70
[ 828.394684] 0000000087690421 ffffffffb329b1e0 ffff8801c7037c38 0000000000000000
[ 828.394708] Call Trace:
[ 828.394868] dump_stack (lib/dump_stack.c:52)
[ 828.395040] ? _atomic_dec_and_lock (lib/dump_stack.c:27)
[ 828.395079] ubsan_epilogue (lib/ubsan.c:165)
[ 828.395101] __ubsan_handle_vla_bound_not_positive (lib/ubsan.c:364)
[ 828.395118] ? __ubsan_handle_out_of_bounds (lib/ubsan.c:352)
[ 828.395179] ? sock_alloc_file (net/socket.c:388)
[ 828.395194] ? sock_splice_read (net/socket.c:356)
[ 828.395217] ? check_preemption_disabled (lib/smp_processor_id.c:52)
[ 828.395244] hash_accept (crypto/algif_hash.c:185 (discriminator 1))
[ 828.395264] SYSC_accept4 (net/socket.c:1476)
[ 828.395282] ? sockfd_lookup_light (net/socket.c:1427)
[ 828.395319] ? _raw_spin_unlock_bh (kernel/locking/spinlock.c:208)
[ 828.395339] ? release_sock (net/core/sock.c:2446)
[ 828.395645] ? hash_accept_parent_nokey (crypto/algif_hash.c:380)
[ 828.396457] ? map_id_down (kernel/user_namespace.c:201)
[ 828.396484] ? SyS_futex (kernel/futex.c:3099)
[ 828.396502] ? do_futex (kernel/futex.c:3099)
[ 828.396519] ? SyS_socket (net/socket.c:1213)
[ 828.396536] ? move_addr_to_kernel (net/socket.c:1213)
[ 828.396552] SyS_accept (net/socket.c:1506)
[ 828.396569] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:186)
[ 828.396596] ? vm_mmap_pgoff (mm/util.c:325)
Which is this code snippet:
static int hash_accept(struct socket *sock, struct socket *newsock, int flags)
{
struct sock *sk = sock->sk;
struct alg_sock *ask = alg_sk(sk);
struct hash_ctx *ctx = ask->private;
struct ahash_request *req = &ctx->req;
char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req))];
Where crypto_ahash_statesize(crypto_ahash_reqtfm(req)) == 0.
Thanks,
Sasha
[toc] | [next] | [standalone]
| From | Herbert Xu <herbert@gondor.apana.org.au> |
|---|---|
| Date | 2016-01-25 15:00 +0100 |
| Message-ID | <qUPQu-4Ie-15@gated-at.bofh.it> |
| In reply to | #1316605 |
On Mon, Jan 25, 2016 at 07:14:20AM -0500, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running the latest -next kernel
> I've hit:
>
> [ 828.386074] UBSAN: Undefined behaviour in crypto/algif_hash.c:185:7
> [ 828.386811] variable length array bound value 0 <= 0
> [ 828.387606] CPU: 1 PID: 17792 Comm: trinity-c313 Not tainted 4.4.0-next-20160122-sasha-00019-gd2a2eb4-dirty #2819
> [ 828.388957] 1ffff10038e06f65 0000000087690421 ffff8801c7037ba8 ffffffffa34474f1
> [ 828.394655] 0000000041b58ab3 ffffffffaf84c518 ffffffffa3447426 ffff8801c7037b70
> [ 828.394684] 0000000087690421 ffffffffb329b1e0 ffff8801c7037c38 0000000000000000
> [ 828.394708] Call Trace:
> [ 828.394868] dump_stack (lib/dump_stack.c:52)
> [ 828.395040] ? _atomic_dec_and_lock (lib/dump_stack.c:27)
> [ 828.395079] ubsan_epilogue (lib/ubsan.c:165)
> [ 828.395101] __ubsan_handle_vla_bound_not_positive (lib/ubsan.c:364)
> [ 828.395118] ? __ubsan_handle_out_of_bounds (lib/ubsan.c:352)
> [ 828.395179] ? sock_alloc_file (net/socket.c:388)
> [ 828.395194] ? sock_splice_read (net/socket.c:356)
> [ 828.395217] ? check_preemption_disabled (lib/smp_processor_id.c:52)
> [ 828.395244] hash_accept (crypto/algif_hash.c:185 (discriminator 1))
> [ 828.395264] SYSC_accept4 (net/socket.c:1476)
> [ 828.395282] ? sockfd_lookup_light (net/socket.c:1427)
> [ 828.395319] ? _raw_spin_unlock_bh (kernel/locking/spinlock.c:208)
> [ 828.395339] ? release_sock (net/core/sock.c:2446)
> [ 828.395645] ? hash_accept_parent_nokey (crypto/algif_hash.c:380)
> [ 828.396457] ? map_id_down (kernel/user_namespace.c:201)
> [ 828.396484] ? SyS_futex (kernel/futex.c:3099)
> [ 828.396502] ? do_futex (kernel/futex.c:3099)
> [ 828.396519] ? SyS_socket (net/socket.c:1213)
> [ 828.396536] ? move_addr_to_kernel (net/socket.c:1213)
> [ 828.396552] SyS_accept (net/socket.c:1506)
> [ 828.396569] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:186)
> [ 828.396596] ? vm_mmap_pgoff (mm/util.c:325)
>
> Which is this code snippet:
>
> static int hash_accept(struct socket *sock, struct socket *newsock, int flags)
> {
> struct sock *sk = sock->sk;
> struct alg_sock *ask = alg_sk(sk);
> struct hash_ctx *ctx = ask->private;
> struct ahash_request *req = &ctx->req;
> char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req))];
>
>
> Where crypto_ahash_statesize(crypto_ahash_reqtfm(req)) == 0.
This should not be possible because we forbid any algorithm with
a zero statesize from being registered. Please tell us what
algorithm you were using that led to this crash.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[toc] | [prev] | [next] | [standalone]
| From | Sasha Levin <sasha.levin@oracle.com> |
|---|---|
| Date | 2016-01-26 14:30 +0100 |
| Message-ID | <qVbR0-4Hb-1@gated-at.bofh.it> |
| In reply to | #1316721 |
On 01/25/2016 08:58 AM, Herbert Xu wrote:
> On Mon, Jan 25, 2016 at 07:14:20AM -0500, Sasha Levin wrote:
>> Hi all,
>>
>> While fuzzing with trinity inside a KVM tools guest running the latest -next kernel
>> I've hit:
>>
>> [ 828.386074] UBSAN: Undefined behaviour in crypto/algif_hash.c:185:7
>> [ 828.386811] variable length array bound value 0 <= 0
>> [ 828.387606] CPU: 1 PID: 17792 Comm: trinity-c313 Not tainted 4.4.0-next-20160122-sasha-00019-gd2a2eb4-dirty #2819
>> [ 828.388957] 1ffff10038e06f65 0000000087690421 ffff8801c7037ba8 ffffffffa34474f1
>> [ 828.394655] 0000000041b58ab3 ffffffffaf84c518 ffffffffa3447426 ffff8801c7037b70
>> [ 828.394684] 0000000087690421 ffffffffb329b1e0 ffff8801c7037c38 0000000000000000
>> [ 828.394708] Call Trace:
>> [ 828.394868] dump_stack (lib/dump_stack.c:52)
>> [ 828.395040] ? _atomic_dec_and_lock (lib/dump_stack.c:27)
>> [ 828.395079] ubsan_epilogue (lib/ubsan.c:165)
>> [ 828.395101] __ubsan_handle_vla_bound_not_positive (lib/ubsan.c:364)
>> [ 828.395118] ? __ubsan_handle_out_of_bounds (lib/ubsan.c:352)
>> [ 828.395179] ? sock_alloc_file (net/socket.c:388)
>> [ 828.395194] ? sock_splice_read (net/socket.c:356)
>> [ 828.395217] ? check_preemption_disabled (lib/smp_processor_id.c:52)
>> [ 828.395244] hash_accept (crypto/algif_hash.c:185 (discriminator 1))
>> [ 828.395264] SYSC_accept4 (net/socket.c:1476)
>> [ 828.395282] ? sockfd_lookup_light (net/socket.c:1427)
>> [ 828.395319] ? _raw_spin_unlock_bh (kernel/locking/spinlock.c:208)
>> [ 828.395339] ? release_sock (net/core/sock.c:2446)
>> [ 828.395645] ? hash_accept_parent_nokey (crypto/algif_hash.c:380)
>> [ 828.396457] ? map_id_down (kernel/user_namespace.c:201)
>> [ 828.396484] ? SyS_futex (kernel/futex.c:3099)
>> [ 828.396502] ? do_futex (kernel/futex.c:3099)
>> [ 828.396519] ? SyS_socket (net/socket.c:1213)
>> [ 828.396536] ? move_addr_to_kernel (net/socket.c:1213)
>> [ 828.396552] SyS_accept (net/socket.c:1506)
>> [ 828.396569] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:186)
>> [ 828.396596] ? vm_mmap_pgoff (mm/util.c:325)
>>
>> Which is this code snippet:
>>
>> static int hash_accept(struct socket *sock, struct socket *newsock, int flags)
>> {
>> struct sock *sk = sock->sk;
>> struct alg_sock *ask = alg_sk(sk);
>> struct hash_ctx *ctx = ask->private;
>> struct ahash_request *req = &ctx->req;
>> char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req))];
>>
>>
>> Where crypto_ahash_statesize(crypto_ahash_reqtfm(req)) == 0.
>
> This should not be possible because we forbid any algorithm with
> a zero statesize from being registered. Please tell us what
> algorithm you were using that led to this crash.
Hey Herbert,
This seems to be happening with "digest_null".
Thanks,
Sasha
[toc] | [prev] | [next] | [standalone]
| From | Herbert Xu <herbert@gondor.apana.org.au> |
|---|---|
| Date | 2016-01-26 15:10 +0100 |
| Message-ID | <qVctH-5ef-15@gated-at.bofh.it> |
| In reply to | #1317908 |
On Tue, Jan 26, 2016 at 08:26:41AM -0500, Sasha Levin wrote: > > This seems to be happening with "digest_null". In that case this is expected as digest_null obviously has no state. So why is a zero-length array disallowed by ubsan? Cheers, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[toc] | [prev] | [next] | [standalone]
| From | Sasha Levin <sasha.levin@oracle.com> |
|---|---|
| Date | 2016-01-26 15:40 +0100 |
| Message-ID | <qVcWM-5sj-57@gated-at.bofh.it> |
| In reply to | #1317939 |
On 01/26/2016 09:07 AM, Herbert Xu wrote: > On Tue, Jan 26, 2016 at 08:26:41AM -0500, Sasha Levin wrote: >> > >> > This seems to be happening with "digest_null". > In that case this is expected as digest_null obviously has no > state. So why is a zero-length array disallowed by ubsan? The C spec forbids it, so ubsan complains :) Thanks, Sasha
[toc] | [prev] | [next] | [standalone]
| From | Herbert Xu <herbert@gondor.apana.org.au> |
|---|---|
| Date | 2016-01-26 15:50 +0100 |
| Message-ID | <qVd6r-5vL-41@gated-at.bofh.it> |
| In reply to | #1317984 |
On Tue, Jan 26, 2016 at 09:30:54AM -0500, Sasha Levin wrote: > > The C spec forbids it, so ubsan complains :) If you really care about this then please send a patch that adds ?: 1 to the size. Cheers, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web