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 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.