From: Sven Eckelmann <sven@narfation.org>
To: "Linus Lüssing" <linus.luessing@c0d3.blue>
Cc: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [PATCH RFC batadv] batman-adv: mcast: fix use-after-free in orig_node RCU release
Date: Sun, 17 May 2026 18:54:09 +0200 [thread overview]
Message-ID: <5073295.GXAFRqVoOG@sven-l14> (raw)
In-Reply-To: <agnvHQNOj2Sn7Thr@sellars>
[-- Attachment #1: Type: text/plain, Size: 2681 bytes --]
On Sunday, 17 May 2026 18:38:53 CEST Linus Lüssing wrote:
> On Thu, May 14, 2026 at 07:41:38PM +0200, Sven Eckelmann wrote:
> > batadv_mcast_purge_orig() removes entries from RCU-protected hlists but
> > does not wait for an RCU grace period before returning. Concurrent RCU
> > readers may still accesses references to those entries at the point of
> > removal. RCU-protected readers trying to operate on entries like
> > orig->mcast_want_all_ipv6_node will then access already freed memory.
>
> This one I don't really get yet. The mcat_want_all_* lists/entries should
> be spinlock protected (&bat_priv->mcast.want_lists_lock), not RCU
> protected?
>
> We don't use RCU for these lists in the first place because within
> the list changes / spinlocks &bat_priv->mcast.num_want_all_*
> atomic counters are increased/decreased. And these atomic counters
> are then used in fast path. Not those lists.
>
Um? I can see RCU modification function here (which are correctly protected
by spinlocks):
static void batadv_mcast_want_ipv4_update(struct batadv_priv *bat_priv,
struct batadv_orig_node *orig,
u8 mcast_flags)
{
struct hlist_node *node = &orig->mcast_want_all_ipv4_node;
struct hlist_head *head = &bat_priv->mcast.want_all_ipv4_list;
lockdep_assert_held(&orig->mcast_handler_lock);
/* switched from flag unset to set */
if (mcast_flags & BATADV_MCAST_WANT_ALL_IPV4 &&
!(orig->mcast_flags & BATADV_MCAST_WANT_ALL_IPV4)) {
[...]
hlist_add_head_rcu(node, head);
[...]
/* switched from flag set to unset */
} else if (!(mcast_flags & BATADV_MCAST_WANT_ALL_IPV4) &&
orig->mcast_flags & BATADV_MCAST_WANT_ALL_IPV4) {
[...]
hlist_del_init_rcu(node);
[...]
}
}
But this looks super RCU-like (without locks):
static int
batadv_mcast_forw_want_all_ipv4(struct batadv_priv *bat_priv,
struct sk_buff *skb, unsigned short vid)
{
struct batadv_orig_node *orig_node;
int ret = NET_XMIT_SUCCESS;
struct sk_buff *newskb;
rcu_read_lock();
hlist_for_each_entry_rcu(orig_node,
&bat_priv->mcast.want_all_ipv4_list,
mcast_want_all_ipv4_node) {
[..]
}
rcu_read_unlock();
return ret;
}
And when you do something like this, you can't try do run these functions in a
free_rcu function. Because you are then missing the RCU grace period. The list
can still be accessed in a parallel running RCU reader and the
batadv_orig_node_free_rcu function might then already have freed the originator.
The reader then goes *KABUMM*.
Or am I missing something and the functions themelf need to be freed from RCU
references (or something else)?
Regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-05-17 16:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-14 17:41 [PATCH RFC batadv] batman-adv: mcast: fix use-after-free in orig_node RCU release Sven Eckelmann
2026-05-17 16:38 ` Linus Lüssing
2026-05-17 16:54 ` Sven Eckelmann [this message]
2026-05-17 17:55 ` Linus Lüssing
2026-05-17 18:08 ` Sven Eckelmann
2026-05-17 21:08 ` Linus Lüssing
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=5073295.GXAFRqVoOG@sven-l14 \
--to=sven@narfation.org \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=linus.luessing@c0d3.blue \
/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