All of lore.kernel.org
 help / color / mirror / Atom feed
* crypto: algif_hash: creating 0 sized array in hash_accept
@ 2016-01-25 12:14 Sasha Levin
  2016-01-25 13:58 ` Herbert Xu
  0 siblings, 1 reply; 6+ messages in thread
From: Sasha Levin @ 2016-01-25 12:14 UTC (permalink / raw)
  To: Herbert Xu, David S. Miller; +Cc: open list:CRYPTO API, LKML

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: crypto: algif_hash: creating 0 sized array in hash_accept
  2016-01-25 12:14 crypto: algif_hash: creating 0 sized array in hash_accept Sasha Levin
@ 2016-01-25 13:58 ` Herbert Xu
  2016-01-26 13:26   ` Sasha Levin
  0 siblings, 1 reply; 6+ messages in thread
From: Herbert Xu @ 2016-01-25 13:58 UTC (permalink / raw)
  To: Sasha Levin; +Cc: David S. Miller, open list:CRYPTO API, LKML

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: crypto: algif_hash: creating 0 sized array in hash_accept
  2016-01-25 13:58 ` Herbert Xu
@ 2016-01-26 13:26   ` Sasha Levin
  2016-01-26 14:07     ` Herbert Xu
  0 siblings, 1 reply; 6+ messages in thread
From: Sasha Levin @ 2016-01-26 13:26 UTC (permalink / raw)
  To: Herbert Xu; +Cc: David S. Miller, open list:CRYPTO API, LKML

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: crypto: algif_hash: creating 0 sized array in hash_accept
  2016-01-26 13:26   ` Sasha Levin
@ 2016-01-26 14:07     ` Herbert Xu
  2016-01-26 14:30       ` Sasha Levin
  0 siblings, 1 reply; 6+ messages in thread
From: Herbert Xu @ 2016-01-26 14:07 UTC (permalink / raw)
  To: Sasha Levin; +Cc: David S. Miller, open list:CRYPTO API, LKML

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: crypto: algif_hash: creating 0 sized array in hash_accept
  2016-01-26 14:07     ` Herbert Xu
@ 2016-01-26 14:30       ` Sasha Levin
  2016-01-26 14:46         ` Herbert Xu
  0 siblings, 1 reply; 6+ messages in thread
From: Sasha Levin @ 2016-01-26 14:30 UTC (permalink / raw)
  To: Herbert Xu; +Cc: David S. Miller, open list:CRYPTO API, LKML

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: crypto: algif_hash: creating 0 sized array in hash_accept
  2016-01-26 14:30       ` Sasha Levin
@ 2016-01-26 14:46         ` Herbert Xu
  0 siblings, 0 replies; 6+ messages in thread
From: Herbert Xu @ 2016-01-26 14:46 UTC (permalink / raw)
  To: Sasha Levin; +Cc: David S. Miller, open list:CRYPTO API, LKML

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-01-26 14:46 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-25 12:14 crypto: algif_hash: creating 0 sized array in hash_accept Sasha Levin
2016-01-25 13:58 ` Herbert Xu
2016-01-26 13:26   ` Sasha Levin
2016-01-26 14:07     ` Herbert Xu
2016-01-26 14:30       ` Sasha Levin
2016-01-26 14:46         ` Herbert Xu

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.