linux-kernel - Re: [PATCH] include/linux: avoid narrowing length parameter values

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: <6BBC53A4-FEB2-44DA-BA80-B7780921FC59@me.com>
Date:	Mon, 18 May 2015 14:43:39 -0600
From:	Louis Langholtz <lou_langholtz@...com>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] include/linux: avoid narrowing length parameter values

On May 18, 2015, at 9:56 AM, Al Viro <viro@...iv.linux.org.uk> wrote:

> On Mon, May 18, 2015 at 09:33:10AM -0600, Louis Langholtz wrote:
>> memcpy_from_msg() and memcpy_to_msg() functions previously called
>> memcpy_fromiovec() and memcpy_toiovec() functions respectively. The
>> memcpy_fromiovec() and memcpy_toiovec() functions took a length parameter
>> of type int. memcpy_from_msg() and memcpy_to_msg() now call
>> copy_from_iter() and copy_to_iter() functions respectively which take a length
>> parameter of type size_t. Most code calling the memcpy_from_msg() and
>> memcpy_to_msg() functions currently pass a length value of type size_t.
>> This patch updates the memcpy_from_msg() and memcpy_to_msg() functions
>> concordantly to take the length parameter of type size_t. This also avoids a potential
>> for data narrowing.
> 
> iov_iter for sendmsg or recvmsg *can't* have more than 2Gb of data; if it
> ever does, it's a serious bug.
> 
> IOW, NAK - that's pointless.

I understand that operationally the change is a no-op given the 2Gb limit you
point out. I still don't understand how using size_t instead of int is pointless
however. The change still increases consistency and adds semantically by
using the type (size_t) established for holding the size of an object.

If the position is that weak-typing is better, I can understand that; I just disagree
then. If the position is that u32 would be better (than int because it more closely
matches the 2Gb design limit presuming that the value also can't ever be
negative), I'd also understand not applying this patch and would agree with that
argument (although I'd be bothered then that so much of the relevant code is
already using size_t).--
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/