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] [day] [month] [year] [list]
Date:   Fri, 26 Feb 2021 14:42:34 +0600
From:   Sabyrzhan Tasbolatov <snovitoll@...il.com>
To:     snovitoll@...il.com
Cc:     dmitry.torokhov@...il.com, linux-input@...r.kernel.org,
        linux-kernel@...r.kernel.org, rydberg@...math.org,
        syzbot+0122fa359a69694395d5@...kaller.appspotmail.com
Subject: Re: [PATCH] drivers/mt: restrict num_slots in input_mt_init_slots()

On Tue,  2 Feb 2021 18:08:07 +0600, Sabyrzhan Tasbolatov wrote:
> syzbot found WARNING in input_mt_init_slots [1] when
> struct_size(mt, slots, num_slots)=0x40006 where num_slots=0x10001,
> which exceeds KMALLOC_MAX_SIZE (0x40000) and causes
> order >= MAX_ORDER condition.
> 
> [1]
> Call Trace:
>  alloc_pages_current+0x18c/0x2a0 mm/mempolicy.c:2267
>  alloc_pages include/linux/gfp.h:547 [inline]
>  kmalloc_order+0x2e/0xb0 mm/slab_common.c:837
>  kmalloc_order_trace+0x14/0x120 mm/slab_common.c:853
>  kmalloc include/linux/slab.h:557 [inline]
>  kzalloc include/linux/slab.h:682 [inline]
>  input_mt_init_slots drivers/input/input-mt.c:49 [inline]
> 
> Reported-by: syzbot+0122fa359a69694395d5@...kaller.appspotmail.com
> Signed-off-by: Sabyrzhan Tasbolatov <snovitoll@...il.com>
> ---
>  drivers/input/input-mt.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/input/input-mt.c b/drivers/input/input-mt.c
> index 44fe6f2f063c..e542f45a45ab 100644
> --- a/drivers/input/input-mt.c
> +++ b/drivers/input/input-mt.c
> @@ -40,13 +40,18 @@ int input_mt_init_slots(struct input_dev *dev, unsigned int num_slots,
>  {
>  	struct input_mt *mt = dev->mt;
>  	int i;
> +	size_t mt_size = 0;
>  
>  	if (!num_slots)
>  		return 0;
>  	if (mt)
>  		return mt->num_slots != num_slots ? -EINVAL : 0;
>  
> -	mt = kzalloc(struct_size(mt, slots, num_slots), GFP_KERNEL);
> +	mt_size = struct_size(mt, slots, num_slots);
> +	if (mt_size > KMALLOC_MAX_SIZE)
> +		return -ENOMEM;
> +
> +	mt = kzalloc(mt_size, GFP_KERNEL);
>  	if (!mt)
>  		goto err_mem;
>  
> -- 

Following-up. I've also just found out that in this function, there is another
allocation with num_slots length:

int input_mt_init_slots(..)
{
	..
	if (flags & INPUT_MT_TRACK) {
		unsigned int n2 = num_slots * num_slots;
		mt->red = kcalloc(n2, sizeof(*mt->red), GFP_KERNEL);
	..

I've checked HID vendors' xrefs for input_mt_init_slots(), most of them
pass >= 5 value to num_slots parameter. So either we should choose some
optimal limit of num_slots or just restrict it with big KMALLOC_MAX_SIZE.

Comments?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ