[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d904eaa7-4ea3-e55e-cfae-8060af021632@gmail.com>
Date: Thu, 5 Apr 2018 12:40:40 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: David Miller <davem@...emloft.net>, edumazet@...gle.com
Cc: netdev@...r.kernel.org, steffen.klassert@...unet.com,
eric.dumazet@...il.com
Subject: Re: [PATCH net 0/6] net: better validate user provided tunnel names
On 04/05/2018 12:21 PM, David Miller wrote:
> From: Eric Dumazet <edumazet@...gle.com>
> Date: Thu, 5 Apr 2018 06:39:25 -0700
>
>> This series changes dev_valid_name() to not attempt reading
>> a possibly too long user-provided device name, then use
>> this helper in five different tunnel providers.
>
> Series applied and queued up for -stable, thanks Eric.
>
> Reading over this series makes me wonder if we generally have an
> off-by-one bug for device names which are exactly IFNAMSIZ.
>
> We validate the size using the test:
>
> if (strlen(name) >= IFNAMSIZ)
> return ERROR;
>
> and thusly after Eric's changes:
>
> if (strnlen(name, IFNAMSIZ) == IFNAMSIZ)
> return ERROR;
>
> This value computed by str{,n}len() doesn't include the trailing null
> byte.
>
> So we will accept a name that has exactly IFNAMSIZ bytes long not
> including the trailing null.
In this case strnlen(name, IFNAMSIZ) returns IFNAMSIZ.
So (strnlen(name, IFNAMSIZ) == IFNAMSIZ) would definitely be true.
The only effect of the change is that strlen() would read 1000 bytes of a
malicious string before we reached the test on the length to reject such name.
While strnlen() is guaranteed to not read more than IFNAMSIZ bytes.
Powered by blists - more mailing lists