mac80211: MLO link removal frees link RX stats percpu without RCU grace

[Maoyi Xie]

Hi Johannes,

I think there is a use after free on the MLO link removal path in
net/mac80211/sta_info.c. The link RX stats percpu buffer is freed while a
concurrent RX softirq can still write to it. I would appreciate it if you
could take a look.

sta_remove_link() frees the link stats and defers only the container:

	sta_info_free_link(&alloc->info);
	kfree_rcu(alloc, rcu_head);

sta_info_free_link() does the free right away:

	free_percpu(link_sta->pcpu_rx_stats);

So the container waits for a grace period but the percpu stats are
reclaimed at once. The RX fast path runs in softirq under rcu_read_lock
only. It resolves link_sta early and writes the percpu stats later:

	stats = this_cpu_ptr(link_sta->pcpu_rx_stats);
	stats->last_signal = status->signal;

A reader that resolved link_sta before the removal NULLed it keeps the
pointer. The container is still alive from the kfree_rcu, so the read of
link_sta->pcpu_rx_stats works. But the percpu block it points to is
already freed. This needs uses_rss. That is when pcpu_rx_stats is
allocated. The trigger is an MLO link removed over the air through a
Multi-Link Reconfiguration element.

The full STA teardown does this safely. __sta_info_destroy calls
synchronize_net() before sta_info_free() frees the deflink stats. The MLO
link removal path has no such barrier. That path was added in
cb71f1d136a6 ("wifi: mac80211: add sta link addition/removal").

I do not have WiFi 7 hardware. This is from reading the code. A small test
that frees the stats buffer and writes it through the live container trips
KASAN with a slab use after free.

Does this look like a real use after free to you? Is the right fix to
defer the percpu free to RCU, like the container already is? I am happy to
send a patch once you confirm.

Kaixuan Li and I found this together.

Thanks,
Maoyi
https://maoyixie.com/