alloc_netdev() may be called with too long name (more that IFNAMSIZ bytes).
Currently this leads to BUG(). Other insane inputs (bad txqs, rxqs) and
even OOM don't lead to BUG(). Made alloc_netdev() return NULL, like on
other errors.
Signed-off-by: Vasiliy Kulikov <redacted>
---
Compile tested.
v2 - fixed checkpatch warning - space before "\n".
net/core/dev.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
On Mon, Feb 14, 2011 at 4:42 PM, Vasiliy Kulikov [off-list ref] wrote:
alloc_netdev() may be called with too long name (more that IFNAMSIZ bytes).
Currently this leads to BUG(). Other insane inputs (bad txqs, rxqs) and
even OOM don't lead to BUG(). Made alloc_netdev() return NULL, like on
other errors.
Alexey,
On Mon, Feb 14, 2011 at 17:16 +0200, Alexey Dobriyan wrote:
On Mon, Feb 14, 2011 at 4:42 PM, Vasiliy Kulikov [off-list ref] wrote:
quoted
alloc_netdev() may be called with too long name (more that IFNAMSIZ bytes).
Currently this leads to BUG(). Other insane inputs (bad txqs, rxqs) and
even OOM don't lead to BUG(). Made alloc_netdev() return NULL, like on
other errors.
size_t alloc_size;
struct net_device *p;
- BUG_ON(strlen(name) >= sizeof(dev->name));
+ if (strnlen(name, sizeof(dev->name)) >= sizeof(dev->name)) {
+ pr_err("alloc_netdev: Too long device name\n");
+ return NULL;
+ }
Netdevice name isn't some random junk you get from userspace, so BUG is fine.
It IS for bluetooth, see net/bluetooth/bnep/core.c: bnep_add_connection() and
net/bluetooth/bnep/sock.c: bnep_sock_ioctl().
And txqs, txqs? Then why do not BUG() on bad txqs too? Why so
insonsistent? BUG() should be called in some critical situation, net
device creation is probably not such a thing.
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
From: Patrick McHardy <hidden> Date: 2011-02-14 15:41:07
Am 14.02.2011 16:16, schrieb Alexey Dobriyan:
On Mon, Feb 14, 2011 at 4:42 PM, Vasiliy Kulikov [off-list ref] wrote:
quoted
alloc_netdev() may be called with too long name (more that IFNAMSIZ bytes).
Currently this leads to BUG(). Other insane inputs (bad txqs, rxqs) and
even OOM don't lead to BUG(). Made alloc_netdev() return NULL, like on
other errors.
quoted
--- a/net/core/dev.c+++ b/net/core/dev.c
@@ -5761,7 +5761,10 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,size_talloc_size;structnet_device*p;-BUG_ON(strlen(name)>=sizeof(dev->name));+if(strnlen(name,sizeof(dev->name))>=sizeof(dev->name)){+pr_err("alloc_netdev: Too long device name\n");+returnNULL;+}
Netdevice name isn't some random junk you get from userspace, so BUG is fine.
I agree, misuse of kernel APIs is not something we need to catch
verbosely.
On Mon, Feb 14, 2011 at 17:16 +0200, Alexey Dobriyan wrote:
quoted
Netdevice name isn't some random junk you get from userspace, so BUG is fine.
It IS for bluetooth, see net/bluetooth/bnep/core.c: bnep_add_connection() and
net/bluetooth/bnep/sock.c: bnep_sock_ioctl().
If bluetooth wants to allow something so foolish, then it's bluetooth's
responsibility to sanity check the arguments before blinding passing
them into kernel APIs which expect sane inputs.
I'm not applying this.
On Mon, Feb 14, 2011 at 17:16 +0200, Alexey Dobriyan wrote:
quoted
Netdevice name isn't some random junk you get from userspace, so BUG is fine.
It IS for bluetooth, see net/bluetooth/bnep/core.c: bnep_add_connection() and
net/bluetooth/bnep/sock.c: bnep_sock_ioctl().
If bluetooth wants to allow something so foolish, then it's bluetooth's
responsibility to sanity check the arguments before blinding passing
them into kernel APIs which expect sane inputs.
I'm not applying this.
Changing to BUG_ON(txqs < 1) and BUG_ON(rxqs < 1) does make sense I think.
Tom
On Mon, Feb 14, 2011 at 17:16 +0200, Alexey Dobriyan wrote:
quoted
Netdevice name isn't some random junk you get from userspace, so BUG is fine.
It IS for bluetooth, see net/bluetooth/bnep/core.c: bnep_add_connection() and
net/bluetooth/bnep/sock.c: bnep_sock_ioctl().
If bluetooth wants to allow something so foolish, then it's bluetooth's
responsibility to sanity check the arguments before blinding passing
them into kernel APIs which expect sane inputs.
I'm not applying this.
Changing to BUG_ON(txqs < 1) and BUG_ON(rxqs < 1) does make sense I think.