From: Johannes Berg <johannes@sipsolutions.net>
To: Zihan Xi <zihanx@nebusec.ai>, linux-wireless@vger.kernel.org
Cc: Ryder Lee <ryder.lee@mediatek.com>, Felix Fietkau <nbd@nbd.name>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Vega <vega@nebusec.ai>, Luxing Yin <root@tr0jan.top>
Subject: Re: [PATCH wireless 1/1] wifi: mac80211: fix mesh fast xmit path deletion UAF
Date: Tue, 08 Sep 2026 10:56:28 +0200 [thread overview]
Message-ID: <0fc3903fc2b6e0b2a01a8b473cd5ce1fa3b57f00.camel@sipsolutions.net> (raw)
In-Reply-To: <94174303640c5e1022b31836770bad75f741afbf.1788845030.git.zihanx@nebusec.ai> (sfid-20260908_082840_904659_5067153E)
On Tue, 2026-09-08 at 06:28 +0000, Zihan Xi wrote:
> mesh_fast_tx_cache() stores raw mesh_path pointers in a persistent
> fast-xmit cache entry. Path deletion flushes currently visible cache
> entries and then schedules the path for RCU freeing, but a sender that
> already holds the path in an RCU read-side section can insert a new
> entry after that flush. Once the lookup RCU section ends, the path is
> freed while the new cache entry still points at it. A later
> mesh_fast_tx_get() then dereferences the freed flags, expiry, or
> next_hop fields.
>
> Mark the path MESH_PATH_DELETED before flushing the cache, and reject
> cache insertion if the mesh path or optional MPP path was deleted while
> the entry was being built. The cache walk lock orders this check with
> deletion flush, so entries inserted before the flush are removed and
> later entries are not cached.
>
> The crash path is ieee80211_mesh_xmit_fast() -> mesh_fast_tx_get().
> The same cache is also consumed by ieee80211_rx_mesh_fast_forward(),
> so the deletion tombstone covers both consumers.
What? You need to start writing your own commit messages.
johannes
prev parent reply other threads:[~2026-09-08 8:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 6:28 [PATCH wireless 0/1] wifi: mac80211: fix mesh fast xmit path deletion UAF Zihan Xi
2026-09-08 6:28 ` [PATCH wireless 1/1] " Zihan Xi
2026-09-08 8:56 ` Johannes Berg [this message]
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=0fc3903fc2b6e0b2a01a8b473cd5ce1fa3b57f00.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@nbd.name \
--cc=root@tr0jan.top \
--cc=ryder.lee@mediatek.com \
--cc=stable@vger.kernel.org \
--cc=vega@nebusec.ai \
--cc=zihanx@nebusec.ai \
/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 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.