netdev - Re: [PATCH] mpls: Add missing RCU-bh read side critical section locking in output path

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:	Thu, 23 Jun 2016 12:00:55 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	buytenh@...tstofly.org
Cc:	netdev@...r.kernel.org, dsa@...ulusnetworks.com,
	roopa@...ulusnetworks.com, rshearma@...cade.com
Subject: Re: [PATCH] mpls: Add missing RCU-bh read side critical section
 locking in output path

From: Lennert Buytenhek <buytenh@...tstofly.org>
Date: Mon, 20 Jun 2016 21:05:27 +0300

> From: David Barroso <dbarroso@...tly.com>
> 
> When locally originated IP traffic hits a route that says to push
> MPLS labels, we'll get a call chain dst_output() -> lwtunnel_output()
> -> mpls_output() -> neigh_xmit() -> ___neigh_lookup_noref() where the
> last function in this chain accesses a RCU-bh protected struct
> neigh_table pointer without us ever having declared an RCU-bh read
> side critical section.
> 
> As in case of locally originated IP traffic we'll be running in process
> context, with softirqs enabled, we can be preempted by a softirq at any
> time, and RCU-bh considers the completion of a softirq as signaling
> the end of any pending read-side critical sections, so if we do get a
> softirq here, we can end up with an unexpected RCU grace period and
> all the nastiness that that comes with.
> 
> This patch makes neigh_xmit() take rcu_read_{,un}lock_bh() around the
> code that expects to be treated as an RCU-bh read side critical section.
> 
> Signed-off-by: David Barroso <dbarroso@...tly.com>
> Signed-off-by: Lennert Buytenhek <lbuytenhek@...tly.com>

Whilst the case that was used to discover this problem was MPLS, that
is not the subsystem where the bug exists and is being fixed.

Therefore please fix your Subject line.

Thanks.