[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120711121102.GB26643@hmsreliant.think-freely.org>
Date: Wed, 11 Jul 2012 08:11:02 -0400
From: Neil Horman <nhorman@...driver.com>
To: Gao feng <gaofeng@...fujitsu.com>
Cc: eric.dumazet@...il.com, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, lizefan@...wei.com, tj@...nel.org,
davem@...emloft.net, Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH v3] net: cgroup: fix access the unallocated memory in
netprio cgroup
On Wed, Jul 11, 2012 at 04:30:06PM +0800, Gao feng wrote:
> there are some out of bound accesses in netprio cgroup.
>
> now before accessing the dev->priomap.priomap array,we only check
> if the dev->priomap exist.and because we don't want to see
> additional bound checkings in fast path, so we should make sure
> that dev->priomap is null or array size of dev->priomap.priomap
> is equal to max_prioidx + 1;
>
> and it's not needed to call extend_netdev_tabel in write_priomap,
> we can only allocate the net device's priomap which we change through
> net_prio.ifpriomap.
>
> this patch add a return value for update_netdev_tables & extend_netdev_table,
> so when new_priomap is allocated failed,write_priomap will stop to access
> the priomap,and return -ENOMEM back to the userspace to tell the user
> what happend.
>
> Change From v2:
> 1. protect extend_netdev_table by RTNL.
> 2. when extend_netdev_table failed,call dev_put to reduce device's refcount.
>
> Signed-off-by: Gao feng <gaofeng@...fujitsu.com>
> Cc: Neil Horman <nhorman@...driver.com>
> Cc: Eric Dumazet <edumazet@...gle.com>
> ---
> net/core/netprio_cgroup.c | 54 ++++++++++++++++++++++++++++++++------------
> 1 files changed, 39 insertions(+), 15 deletions(-)
>
I still think the use of max_priomap in write_priomap is racy (please see my
previous note).
Neil
--
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/
Powered by blists - more mailing lists