netdev - Re: [NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt

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]

Date:	Wed, 9 Jan 2008 11:37:27 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	davem@...emloft.net, dipankar@...ibm.com, netdev@...r.kernel.org
Subject: Re: [NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache

On Wed, 9 Jan 2008 20:46:37 +1100
Herbert Xu <herbert@...dor.apana.org.au> wrote:

> On Wed, Jan 09, 2008 at 08:38:56AM +0100, Eric Dumazet wrote:
> > 
> > I am not sure this is valid, since it will do this :
> > 
> > r = rt_hash_table[st->bucket].chain;
> > if (r)
> >     return rcu_dereference(r);
> > 
> > So compiler might be dumb enough do dereference 
> > &rt_hash_table[st->bucket].chain two times.
> 
> That wouldn't be a problem at all.  The key is to add a barrier between
> reading the pointer:
> 
> 	r = rt_hash_table[st->bucket].chain
> 
> and dereferencing it later, e.g.,
> 
> 	r->u.dst.rt_next
> 
> The barrier is there so that when we dereference r we don't read
> stale cache that was there before the memory at r was initialised.
> How many times you read the pointer value before the barrier is
> irrelevant to the effectiveness of the barrier preceding the
> dereference.

You are absolutely right Herbert, so I changed the patch to :

[NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache

In rt_cache_get_next(), no need to guard seq->private by a rcu_dereference()
since seq is private to the thread running this function. Reading seq.private
once (as guaranted bu rcu_dereference()) or several time if compiler really is 
dumb enough wont change the result.

But we miss real spots where rcu_dereference() are needed, both in 
rt_cache_get_first() and rt_cache_get_next()

Signed-off-by: Eric Dumazet <dada1@...mosbay.com>
Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index d337706..28484f3 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -283,12 +283,12 @@ static struct rtable *rt_cache_get_first(struct seq_file *seq)
 			break;
 		rcu_read_unlock_bh();
 	}
-	return r;
+	return rcu_dereference(r);
 }
 
 static struct rtable *rt_cache_get_next(struct seq_file *seq, struct rtable *r)
 {
-	struct rt_cache_iter_state *st = rcu_dereference(seq->private);
+	struct rt_cache_iter_state *st = seq->private;
 
 	r = r->u.dst.rt_next;
 	while (!r) {
@@ -298,7 +298,7 @@ static struct rtable *rt_cache_get_next(struct seq_file *seq, struct rtable *r)
 		rcu_read_lock_bh();
 		r = rt_hash_table[st->bucket].chain;
 	}
-	return r;
+	return rcu_dereference(r);
 }
 
 static struct rtable *rt_cache_get_idx(struct seq_file *seq, loff_t pos)
--
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