From: Jinjie Ruan <ruanjinjie@huawei.com>
To: <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
<pabeni@redhat.com>, <horms@kernel.org>, <nb@tipi-net.de>,
<kuniyu@google.com>, <sdf@fomichev.me>, <liuhangbin@gmail.com>,
<da-x@monatomic.org>, <jeff@garzik.org>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Cc: <ruanjinjie@huawei.com>
Subject: [PATCH net-next v3 1/2] 8021q: Fix data race when publishing vlan net_device pointers
Date: Wed, 2 Sep 2026 15:33:33 +0800 [thread overview]
Message-ID: <20260902073334.397685-2-ruanjinjie@huawei.com> (raw)
In-Reply-To: <20260902073334.397685-1-ruanjinjie@huawei.com>
A plain C read and assignment of the net_device pointer
in the vlan_devices_arrays leaf entries lack proper atomicity
and ordering barriers. A concurrent lockless reader on the packet
receive fast-path could observe a torn or partially initialized
net_device pointer, leading to a potential out-of-bounds read or kernel
panic.
The data race occurs between the netlink/ioctl configuration paths
(holding the per-netns rtnl_nets_lock or RTNL lock) and the softirq
receive fast-path (holding rcu_read_lock()):
CPU 0 (Writer, rtnl_nets_lock/RTNL) CPU 1 (Reader, rcu_read_lock())
----------------------------------- -------------------------------
rtnetlink_rcv_msg()
// RTM_NEWLINK handler with RTNL_FLAG_DOIT_PERNET
rtnl_newlink()
ops->newlink() == vlan_newlink()
OR
vlan_ioctl_handler()
[ADD_VLAN_CMD] -> register_vlan_device()
register_vlan_dev()
vlan_group_set_device()
netif_receive_skb_core()
vlan_do_receive()
vlan_find_dev()
__vlan_group_get_device()
// Speculative / torn read
[Loads bad net_device *]
[Plain C store]
array[vlan_id] = dev;
// Dereferences bad pointer
// during device status check
vlan_dev->flags (PANIC!)
Fix this by using rcu_assign_pointer() in vlan_group_set_device()
and rcu_dereference_raw() in __vlan_group_get_device() to enforce
proper ordering and memory atomicity for the leaf entry traversal.
Cc: stable@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Simon Horman <horms@kernel.org>
Cc: Stanislav Fomichev <sdf@fomichev.me>
Cc: Kuniyuki Iwashima <kuniyu@google.com>
Cc: Nicolai Buchwitz <nb@tipi-net.de>
Cc: Dan Aloni <da-x@monatomic.org>
Cc: Jeff Garzik <jeff@garzik.org>
Fixes: 5c15bdec5c38 ("[VLAN]: Avoid a 4-order allocation.")
Link: https://sashiko.dev/#/patchset/20260825095422.3166067-1-ruanjinjie%40huawei.com
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
net/8021q/vlan.c | 2 +-
net/8021q/vlan.h | 12 ++++++------
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 2d2efb877975..6df80cad40a2 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -49,7 +49,7 @@ const char vlan_version[] = DRV_VERSION;
static int vlan_group_prealloc_vid(struct vlan_group *vg,
__be16 vlan_proto, u16 vlan_id)
{
- struct net_device **array;
+ struct net_device __rcu **array;
unsigned int vidx;
unsigned int size;
int pidx;
diff --git a/net/8021q/vlan.h b/net/8021q/vlan.h
index c41caaf94095..3cb4c8294130 100644
--- a/net/8021q/vlan.h
+++ b/net/8021q/vlan.h
@@ -22,8 +22,8 @@ enum vlan_protos {
struct vlan_group {
unsigned int nr_vlan_devs;
struct hlist_node hlist; /* linked list */
- struct net_device **vlan_devices_arrays[VLAN_PROTO_NUM]
- [VLAN_GROUP_ARRAY_SPLIT_PARTS];
+ struct net_device __rcu **vlan_devices_arrays[VLAN_PROTO_NUM]
+ [VLAN_GROUP_ARRAY_SPLIT_PARTS];
};
struct vlan_info {
@@ -54,7 +54,7 @@ static inline struct net_device *__vlan_group_get_device(struct vlan_group *vg,
unsigned int pidx,
u16 vlan_id)
{
- struct net_device **array;
+ struct net_device __rcu **array;
array = vg->vlan_devices_arrays[pidx]
[vlan_id / VLAN_GROUP_ARRAY_PART_LEN];
@@ -62,7 +62,7 @@ static inline struct net_device *__vlan_group_get_device(struct vlan_group *vg,
/* paired with smp_wmb() in vlan_group_prealloc_vid() */
smp_rmb();
- return array ? array[vlan_id % VLAN_GROUP_ARRAY_PART_LEN] : NULL;
+ return array ? rcu_dereference_raw(array[vlan_id % VLAN_GROUP_ARRAY_PART_LEN]) : NULL;
}
static inline struct net_device *vlan_group_get_device(struct vlan_group *vg,
@@ -82,13 +82,13 @@ static inline void vlan_group_set_device(struct vlan_group *vg,
struct net_device *dev)
{
int pidx = vlan_proto_idx(vlan_proto);
- struct net_device **array;
+ struct net_device __rcu **array;
if (!vg || pidx < 0)
return;
array = vg->vlan_devices_arrays[pidx]
[vlan_id / VLAN_GROUP_ARRAY_PART_LEN];
- array[vlan_id % VLAN_GROUP_ARRAY_PART_LEN] = dev;
+ rcu_assign_pointer(array[vlan_id % VLAN_GROUP_ARRAY_PART_LEN], dev);
}
/* Must be invoked with rcu_read_lock or with RTNL. */
--
2.34.1
next prev parent reply other threads:[~2026-09-02 7:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 7:33 [PATCH net-next v3 0/2] 8021q: publish vlan_devices_arrays entries with acquire/release Jinjie Ruan
2026-09-02 7:33 ` Jinjie Ruan [this message]
2026-09-02 7:33 ` [PATCH net-next v3 2/2] " Jinjie Ruan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260902073334.397685-2-ruanjinjie@huawei.com \
--to=ruanjinjie@huawei.com \
--cc=da-x@monatomic.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jeff@garzik.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liuhangbin@gmail.com \
--cc=nb@tipi-net.de \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox