[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <512E780E.5050204@redhat.com>
Date: Wed, 27 Feb 2013 22:18:06 +0100
From: Daniel Borkmann <dborkman@...hat.com>
To: Guenter Roeck <linux@...ck-us.net>
CC: David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] net: af_packet: Validate parameter size for PACKET_HDRLEN
control message
On 02/27/2013 09:33 PM, Guenter Roeck wrote:
> On Wed, Feb 27, 2013 at 03:26:30PM -0500, David Miller wrote:
>> From: Daniel Borkmann <dborkman@...hat.com>
>> Date: Wed, 27 Feb 2013 21:22:17 +0100
>>
>>> On 02/27/2013 08:46 PM, Guenter Roeck wrote:
>>>> Building af_packet may fail with
>>>>
>>>> In function ‘copy_from_user’,
>>>> inlined from ‘packet_getsockopt’ at
>>>> net/packet/af_packet.c:3215:21:
>>>> arch/x86/include/asm/uaccess_32.h:211:26: error: call to
>>>> ‘copy_from_user_overflow’ declared with attribute error:
>>>> copy_from_user()
>>>> buffer size is not provably correct
>>>>
>>>> if built with W=1 due to a missing parameter size validation.
>>>>
>>>> Signed-off-by: Guenter Roeck <linux@...ck-us.net>
>>>> ---
>>>> net/packet/af_packet.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
>>>> index c7bfeff..1976b23 100644
>>>> --- a/net/packet/af_packet.c
>>>> +++ b/net/packet/af_packet.c
>>>> @@ -3210,6 +3210,8 @@ static int packet_getsockopt(struct socket
>>>> *sock, int level, int optname,
>>>> val = po->tp_version;
>>>> break;
>>>> case PACKET_HDRLEN:
>>>> + if (len < sizeof(int))
>>>> + return -EINVAL;
>>>
>>> I think this could break some user space applications here, those who
>>> e.g. only pass
>>> an uint16_t to packet_getsockopt with PACKET_HDRLEN.
>>
>> Well, their shit is broken on big endian then.
>
> There must be something else going on anyway ... yes, my patch fixes the
> warning/error, but copy_from_user should only bail out if the copy size
> can be larger than the provided buffer (unless I misunderstand the code
> in copy_from_user). And the second check should take care of that.
Fair enough, from what I read the implementation on x86_64 uses gcc's
__builtin_object_size(<X>, 0) [1]. Since the <to> (<X>) argument is known
at compile time (val:int), __builtin_object_size() will return sizeof(int)-1,
the number of bytes from val start to the end of the object val pointer
points to. Since our length that we pass can be [0, sizeof(int)] the
compiler cannot prove it, if the copy_from_user() buffer size is correct.
Thus, "buffer size is not provably correct". Applications not passing int
to this getsockopt(2) are screwed up then anyway.
[1] http://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists