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] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180405.152111.2211916878014180558.davem@davemloft.net>
Date:   Thu, 05 Apr 2018 15:21:11 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     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

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.

Then we will copy IFNAMSIZ bytes, minus 1, into the device name and
then tack on the trailling null byte.

So essentially we will set the final non-null byte in the string to
a null byte.

Am I misreading things?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ