From: Sven Eckelmann <sven@narfation.org>
To: sashiko-reviews@lists.linux.dev
Cc: sw@simonwunderlich.de, marek.lindner@mailbox.org,
antonio@mandelbit.com, b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [PATCH batadv 3/3] batman-adv: use GFP_KERNEL allocations for the wifi detection cache
Date: Wed, 03 Jun 2026 11:02:23 +0200 [thread overview]
Message-ID: <2275479.Mh6RI2rZIc@ripper> (raw)
In-Reply-To: <20260603045118.0625E1F00893@smtp.kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]
On Wednesday, 3 June 2026 06:51:17 CEST sashiko-bot@kernel.org wrote:
> [Severity: High]
> This isn't a bug introduced by this patch, but while looking at the
> rhashtable usage in this file, I noticed that rhashtable_lookup_fast() is
> called without rcu_read_lock() in batadv_wifi_net_device_update():
>
> net/batman-adv/hard-interface.c:batadv_wifi_net_device_update() {
> ...
> wifi_flags = batadv_wifi_flags_evaluate(net_dev);
> device_state = rhashtable_lookup_fast(&batadv_wifi_net_devices,
> &net_dev,
> batadv_wifi_net_devices_params);
> ...
> }
>
> And similarly in batadv_wifi_net_device_unregister():
>
> net/batman-adv/hard-interface.c:batadv_wifi_net_device_unregister() {
> ...
> device_state = rhashtable_lookup_fast(&batadv_wifi_net_devices,
> &net_dev,
> batadv_wifi_net_devices_params);
> ...
> }
>
> Can this lead to a use-after-free on the bucket array?
>
> Since batadv_wifi_net_devices is initialized with automatic_shrinking = true,
> it can be asynchronously resized by a background worker at any time. This
> worker frees the old bucket array via kfree_rcu(). Without an active RCU
> read-side critical section, couldn't the RCU grace period end while
> rhashtable_lookup_fast() is still iterating?
Would be nice if someone else can double check this. But this doesn't seem to
be valid:
static __always_inline void *rhashtable_lookup_fast(
struct rhashtable *ht, const void *key,
const struct rhashtable_params params)
{
void *obj;
rcu_read_lock();
obj = rhashtable_lookup(ht, key, params);
rcu_read_unlock();
return obj;
}
So, rhashtable_lookup_fast() takes rcu_read_lock() itself. And the returned obj
cannot be freed because all functions mentioned here are protected by the
rtnl_lock().
We are therefore also fulfilling the requirement from the
rhashtable_lookup_fast comment:
* Only use this function when you have other mechanisms guaranteeing
* that the object won't go away after the RCU read lock is released.
Regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
prev parent reply other threads:[~2026-06-03 9:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-03 4:21 [PATCH batadv 0/3] batman-adv: wifi flags cache cleanup Sven Eckelmann
2026-06-03 4:21 ` [PATCH batadv 1/3] batman-adv: correct batadv_wifi_* kernel-doc Sven Eckelmann
2026-06-03 4:21 ` [PATCH batadv 2/3] batman-adv: drop duplicated wifi_flags assigned Sven Eckelmann
2026-06-03 4:21 ` [PATCH batadv 3/3] batman-adv: use GFP_KERNEL allocations for the wifi detection cache Sven Eckelmann
[not found] ` <20260603045118.0625E1F00893@smtp.kernel.org>
2026-06-03 9:02 ` Sven Eckelmann [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=2275479.Mh6RI2rZIc@ripper \
--to=sven@narfation.org \
--cc=antonio@mandelbit.com \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=marek.lindner@mailbox.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sw@simonwunderlich.de \
/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