netdev - Re: [PATCH net] net: bridge: br_vlan_get_pvid_rcu() should dereference the VLAN group under RCU

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] [day] [month] [year] [list]

Message-Id: <20200921.173833.705760978025831604.davem@davemloft.net>
Date:   Mon, 21 Sep 2020 17:38:33 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     vladimir.oltean@....com
Cc:     netdev@...r.kernel.org, bridge@...ts.linux-foundation.org,
        kuba@...nel.org, roopa@...dia.com, nikolay@...dia.com,
        pablo@...filter.org, andrew@...n.ch, f.fainelli@...il.com,
        vivien.didelot@...il.com
Subject: Re: [PATCH net] net: bridge: br_vlan_get_pvid_rcu() should
 dereference the VLAN group under RCU

From: Vladimir Oltean <vladimir.oltean@....com>
Date: Tue, 22 Sep 2020 01:07:09 +0300

> When calling the RCU brother of br_vlan_get_pvid(), lockdep warns:
> 
> =============================
> WARNING: suspicious RCU usage
> 5.9.0-rc3-01631-g13c17acb8e38-dirty #814 Not tainted
> -----------------------------
> net/bridge/br_private.h:1054 suspicious rcu_dereference_protected() usage!
> 
> Call trace:
>  lockdep_rcu_suspicious+0xd4/0xf8
>  __br_vlan_get_pvid+0xc0/0x100
>  br_vlan_get_pvid_rcu+0x78/0x108
> 
> The warning is because br_vlan_get_pvid_rcu() calls nbp_vlan_group()
> which calls rtnl_dereference() instead of rcu_dereference(). In turn,
> rtnl_dereference() calls rcu_dereference_protected() which assumes
> operation under an RCU write-side critical section, which obviously is
> not the case here. So, when the incorrect primitive is used to access
> the RCU-protected VLAN group pointer, READ_ONCE() is not used, which may
> cause various unexpected problems.
> 
> I'm sad to say that br_vlan_get_pvid() and br_vlan_get_pvid_rcu() cannot
> share the same implementation. So fix the bug by splitting the 2
> functions, and making br_vlan_get_pvid_rcu() retrieve the VLAN groups
> under proper locking annotations.
> 
> Fixes: 7582f5b70f9a ("bridge: add br_vlan_get_pvid_rcu()")
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>

Applied and queued up for -stable, thank you.