linux-kernel - Re: [PATCH net-next] ptr_ring: fix integer overflow

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180125154255-mutt-send-email-mst@kernel.org>
Date:   Thu, 25 Jan 2018 15:45:25 +0200
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     Jason Wang <jasowang@...hat.com>
Cc:     linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        John Fastabend <john.fastabend@...il.com>
Subject: Re: [PATCH net-next] ptr_ring: fix integer overflow

On Thu, Jan 25, 2018 at 03:31:42PM +0800, Jason Wang wrote:
> We try to allocate one more entry for lockless peeking. The adding
> operation may overflow which causes zero to be passed to kmalloc().
> In this case, it returns ZERO_SIZE_PTR without any notice by ptr
> ring. Try to do producing or consuming on such ring will lead NULL
> dereference. Fix this detect and fail early.
> 
> Fixes: bcecb4bbf88a ("net: ptr_ring: otherwise safe empty checks can overrun array bounds")
> Reported-by: syzbot+87678bcf753b44c39b67@...kaller.appspotmail.com
> Cc: John Fastabend <john.fastabend@...il.com>
> Signed-off-by: Jason Wang <jasowang@...hat.com>

Ugh that's just way too ugly.
I'll work on dropping the extra + 1 - but calling this
function with -1 size is the real source of the bug.
Do you know how come we do that?

> ---
>  include/linux/ptr_ring.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
> index 9ca1726..3f99484 100644
> --- a/include/linux/ptr_ring.h
> +++ b/include/linux/ptr_ring.h
> @@ -453,6 +453,8 @@ static inline int ptr_ring_consume_batched_bh(struct ptr_ring *r,
>  
>  static inline void **__ptr_ring_init_queue_alloc(unsigned int size, gfp_t gfp)
>  {
> +	if (unlikely(size + 1 == 0))
> +		return NULL;
>  	/* Allocate an extra dummy element at end of ring to avoid consumer head
>  	 * or produce head access past the end of the array. Possible when
>  	 * producer/consumer operations and __ptr_ring_peek operations run in
> -- 
> 2.7.4