linux-kernel - Re: [PATCH 0/2] Fixes packet processes after vif is stopped

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z9cq3A0bqQxmvo42@pilgrim>
Date: Sun, 16 Mar 2025 20:47:40 +0100
From: Remi Pommarel <repk@...plefau.lt>
To: linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: Johannes Berg <johannes@...solutions.net>
Subject: Re: [PATCH 0/2] Fixes packet processes after vif is stopped

On Fri, Mar 14, 2025 at 12:04:23PM +0100, Remi Pommarel wrote:
> Those are a couple of fixes that prevent crashes due to processing
> packets (especially multicast ones) for TX after vif is stopped (either
> after a mesh interface left the group or interface is put down).
> 
> The first one ensure the key info passed to drivers through ieee80211
> skb control block is up to date, even after key removal.
> 
> The second one ensure no packets get processed after vif driver private
> data is cleared in ieee80211_do_stop().
> 
> As I tried to explain in second patch footnote, I can still see a
> theoretical reason that packets get queued after ieee80211_do_stop()
> call. But I was not able to reproduce it, so I may be missing a
> something here; making that more as an open question.

And I forgot to include the footnote in Patch 2/2. I was worried that
because the rcu_read_lock() in __ieee80211_subif_start_xmit() is taken
only after the sdata running state it could create a small window during
which a packet could still be enqueued passed the synchronize_rcu() of
ieee80211_do_stop(). But after digging a bit more, it seems that
all __ieee80211_subif_start_xmit() callers (e.g. __dev_queue_xmit())
take the rcu_read_lock() already. So please ignore this last remark.

Regards,

-- 
Remi