* [PATCH net v3] vxlan: keep the last remote linked during FDB flush
@ 2026-08-10 14:41 David Lee
2026-08-10 15:48 ` Ido Schimmel
0 siblings, 1 reply; 3+ messages in thread
From: David Lee @ 2026-08-10 14:41 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni
Cc: Kyle Zeng, Dominik 'Disconnect3d' Czarnota,
Sven Eckelmann, Petr Machata, Amit Cohen, Ido Schimmel,
Kuniyuki Iwashima, netdev, linux-kernel, stable, David Lee
From: Kyle Zeng <kylebot@openai.com>
A non-nexthop FDB entry is expected to have at least one remote while it
remains reachable through the FDB hash table. A filtered bulk flush
violates this invariant when every remote matches: It unlinks the last
remote in vxlan_fdb_dst_destroy() and only afterwards tells vxlan_flush()
to destroy the parent FDB entry.
An RCU reader can find the parent during this interval.
first_remote_rcu() then applies list_entry_rcu() to the empty list head,
producing an invalid remote pointer that the receive learning path can
read from and write to.
When a matching remote is the sole remaining remote, leave it linked and
ask the caller to destroy the entire FDB entry. vxlan_fdb_destroy() keeps
the remote attached while sending the deletion notification and removing
the parent from the lookup structures.
Fixes: c499fccb71cb ("vxlan: vxlan_core: Support FDB flushing by destination VNI")
Cc: stable@vger.kernel.org
Suggested-by: Ido Schimmel <idosch@nvidia.com>
Assisted-by: Codex:gpt-5.6-sol Codex:gpt-5.5-cyber
Signed-off-by: Kyle Zeng <kylebot@openai.com>
Co-developed-by: David Lee <david.lee@trailofbits.com>
Signed-off-by: David Lee <david.lee@trailofbits.com>
---
Changes in v3:
- Remove remotes_flushed and the redundant final p_destroy_fdb assignment,
as suggested by Ido Schimmel; the caller initializes the flag to false.
Changes in v2:
- Add the net tree prefix to the subject.
- Restore Kyle Zeng as the patch author and correct the sign-off chain.
- Move the research credit below the commit-message separator.
- Add the recipients reported by netdev CI.
v1: https://lore.kernel.org/all/20260731141311.570187-1-david.lee@trailofbits.com/
Bug found and triaged by OpenAI Security Research and
validated by Trail of Bits.
Trail of Bits has a reproducer for this bug that triggers a
KASAN slab-out-of-bounds read in vxlan_snoop() and can share if needed.
drivers/net/vxlan/vxlan_core.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c
index d834a4865..0c42cfd96 100644
--- a/drivers/net/vxlan/vxlan_core.c
+++ b/drivers/net/vxlan/vxlan_core.c
@@ -3051,18 +3051,19 @@ vxlan_fdb_flush_match_remotes(struct vxlan_fdb *f, struct vxlan_dev *vxlan,
const struct vxlan_fdb_flush_desc *desc,
bool *p_destroy_fdb)
{
- bool remotes_flushed = false;
struct vxlan_rdst *rd, *tmp;
list_for_each_entry_safe(rd, tmp, &f->remotes, list) {
if (!vxlan_fdb_flush_remote_matches(desc, rd))
continue;
+ if (list_is_singular(&f->remotes)) {
+ *p_destroy_fdb = true;
+ return;
+ }
+
vxlan_fdb_dst_destroy(vxlan, f, rd, true);
- remotes_flushed = true;
}
-
- *p_destroy_fdb = remotes_flushed && list_empty(&f->remotes);
}
/* Purge the forwarding table */
--
2.53.0
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH net v3] vxlan: keep the last remote linked during FDB flush
2026-08-10 14:41 [PATCH net v3] vxlan: keep the last remote linked during FDB flush David Lee
@ 2026-08-10 15:48 ` Ido Schimmel
[not found] ` <CAC_etQG00pK5AT7n+BCxiRFbc_LWBkyBYSDhV-Ngnie6XBq=mQ@mail.gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Ido Schimmel @ 2026-08-10 15:48 UTC (permalink / raw)
To: David Lee
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, Kyle Zeng,
Dominik 'Disconnect3d' Czarnota, Sven Eckelmann,
Petr Machata, Amit Cohen, Kuniyuki Iwashima, netdev, linux-kernel,
stable
On Mon, Aug 10, 2026 at 02:41:14PM +0000, David Lee wrote:
> From: Kyle Zeng <kylebot@openai.com>
>
> A non-nexthop FDB entry is expected to have at least one remote while it
> remains reachable through the FDB hash table. A filtered bulk flush
> violates this invariant when every remote matches: It unlinks the last
> remote in vxlan_fdb_dst_destroy() and only afterwards tells vxlan_flush()
> to destroy the parent FDB entry.
>
> An RCU reader can find the parent during this interval.
> first_remote_rcu() then applies list_entry_rcu() to the empty list head,
> producing an invalid remote pointer that the receive learning path can
> read from and write to.
>
> When a matching remote is the sole remaining remote, leave it linked and
> ask the caller to destroy the entire FDB entry. vxlan_fdb_destroy() keeps
> the remote attached while sending the deletion notification and removing
> the parent from the lookup structures.
>
> Fixes: c499fccb71cb ("vxlan: vxlan_core: Support FDB flushing by destination VNI")
> Cc: stable@vger.kernel.org
> Suggested-by: Ido Schimmel <idosch@nvidia.com>
This tag is not really appropriate here since I didn't suggest the fix,
but only a small cleanup. Anyway, not a big deal.
> Assisted-by: Codex:gpt-5.6-sol Codex:gpt-5.5-cyber
> Signed-off-by: Kyle Zeng <kylebot@openai.com>
> Co-developed-by: David Lee <david.lee@trailofbits.com>
> Signed-off-by: David Lee <david.lee@trailofbits.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-08-10 18:28 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-10 14:41 [PATCH net v3] vxlan: keep the last remote linked during FDB flush David Lee
2026-08-10 15:48 ` Ido Schimmel
[not found] ` <CAC_etQG00pK5AT7n+BCxiRFbc_LWBkyBYSDhV-Ngnie6XBq=mQ@mail.gmail.com>
2026-08-10 18:28 ` Jakub Kicinski
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.