netdev - Re: [PATCH net V3 2/2] ptr_ring: fail on large queue size (>64K)

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 8 Feb 2018 15:11:22 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     "Michael S. Tsirkin" <mst@...hat.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net V3 2/2] ptr_ring: fail on large queue size (>64K)



On 2018年02月08日 12:52, Michael S. Tsirkin wrote:
> On Thu, Feb 08, 2018 at 11:59:25AM +0800, Jason Wang wrote:
>> We need limit the maximum size of queue, otherwise it may cause
>> several side effects e.g slab will warn when the size exceeds
>> KMALLOC_MAX_SIZE. Using KMALLOC_MAX_SIZE still looks too so this patch
>> tries to limit it to 64K. This value could be revisited if we found a
>> real case that needs more.
>>
>> Reported-by: syzbot+e4d4f9ddd4295539735d@...kaller.appspotmail.com
>> Fixes: 2e0ab8ca83c12 ("ptr_ring: array based FIFO for pointers")
>> Signed-off-by: Jason Wang <jasowang@...hat.com>
>> ---
>>   include/linux/ptr_ring.h | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
>> index 2af71a7..5858d48 100644
>> --- a/include/linux/ptr_ring.h
>> +++ b/include/linux/ptr_ring.h
>> @@ -44,6 +44,8 @@ struct ptr_ring {
>>   	void **queue;
>>   };
>>   
> Seems like a weird location for a define. Either put defines on
> top of the file, or near where they are used. I prefer the
> second option.

Ok.

>
>> +#define PTR_RING_MAX_ALLOC 65536
>> +
> I guess it's an arbitrary number. Seems like a sufficiently large one,
> but pls add a comment so readers don't wonder. And please explain what
> it does:
>
> /* Callers can create ptr_ring structures with userspace-supplied
>   * parameters. This sets a limit on the size to make that usecase
>   * safe. If you ever change this, make sure to audit all callers.
>   */
>
> Also I think we should generally use either hex 0x10000 or (1 << 16).

I agree the number is arbitrary, so I still prefer the KMALLOC_MAX_SIZE 
especially consider it was used by pfifo_fast now. Try to limit it to an 
arbitrary may break lots of exist setups. E.g just google "txqueuelen 
100000" can give me a lots of search results.

We can do any kind of optimization on top but not for -net now.

Thanks

>
>>   /* Note: callers invoking this in a loop must use a compiler barrier,
>>    * for example cpu_relax().
>>    *
>> @@ -466,6 +468,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 (size > PTR_RING_MAX_ALLOC)
>> +		return NULL;
>>   	return kvmalloc_array(size, sizeof(void *), gfp | __GFP_ZERO);
>>   }
>>   
>> -- 
>> 2.7.4