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]
Message-ID: <alpine.DEB.2.00.1202161442320.26083@router.home>
Date:	Thu, 16 Feb 2012 14:47:00 -0600 (CST)
From:	Christoph Lameter <cl@...ux.com>
To:	Xi Wang <xi.wang@...il.com>
cc:	Pekka Enberg <penberg@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	Jesper Juhl <jj@...osbits.net>, Jens Axboe <axboe@...nel.dk>,
	linux-kernel@...r.kernel.org, Matt Mackall <mpm@...enic.com>,
	David Rientjes <rientjes@...gle.com>
Subject: Re: Uninline kcalloc

On Thu, 16 Feb 2012, Xi Wang wrote:

> > The use of a function or macro makes the overflow check much more
> > universal and allows these array allocations to occur with different
> > allocation functions throughout the kernel.
>
> No, it does NOT.  It can be easily misued to introduce more bugs.
>
> 1) Should calculate_array_size() return 0 on overflow, as you
>    orginally proposed?

I thought you worked that out?

> No, as Dan, Pekka, and some others already pointed out.
>
> 2) Should calculate_array_size() return something like
>    KMALLOC_MAX_SIZE + 1?
>
> No, because you intended to use it with other allocators such as
> vmalloc().

vmalloc will also fail if you pass a large number.

> 3) Should calculate_array_size() return ULONG_MAX/SIZE_MAX/-1?
>
> No!  Consider devres_alloc() you mentioned.  Then you do
>
> devres_alloc(..., calculate_array_size(n, size), ...).
>
> It internally invokes kmalloc() with allocation size:
>
> sizeof(struct devres) + calculate_array_size(n, size).

That is an addition which is less likely to overflow. Especially if you
return MAX_ORDER << PAGE_SIZE from the array size calculation.

It would be best to be universal if you want to introduce size overflow
checking rather than just dealing with one case and let the rest of the
kernel fend for themselves. I think we need something like
calculate_array_size() with proper error handling (and no I am not
particular set on having it done a particular way. Just that is it done).


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ