CVE-2026-97599: ieee802154: hwsim: serialize pib updates to fix double-free
In the Linux kernel, the following vulnerability has been resolved:
ieee802154: hwsim: serialize pib updates to fix double-free
hwsimupdatepib() does an unserialized read-swap-free of phy->pib:
pibold = rtnldereference(phy->pib); ... rcuassignpointer(phy->pib, pib); kfreercu(pibold, rcu);
It assumes the RTNL is held, but ->setchannel is not always called under it: the mac802154 scan worker changes channels via drvsetchannel() without the RTNL. Such an update can race an RTNL-held one on the same phy; both read the same pibold and both kfreercu() it, double-freeing the object. With SLUB percpu sheaves batching kfreercu(), this surfaces as a KASAN invalid-free in rcufreesheaf().
struct hwsimphy has no lock for pib. Add one and make the swap atomic with rcureplacepointer() under it, dropping the misleading rtnldereference().
Affected Software
Event History
Frequently Asked Questions
What systems are exposed to this race condition?
Systems using the Linux kernel's IEEE 802.15.4 hwsim implementation are exposed when updates to the same simulated PHY's PIB can occur concurrently. The race involves a channel change initiated by the mac802154 scan worker and another PIB update that is performed while RTNL is held.
What must occur for the double-free to be triggered?
Two concurrent PIB updates must operate on the same hwsim PHY. Both updates can read the same existing PIB pointer before either replaces it, causing each to schedule that same object for kfree_rcu() and resulting in a double-free.
How might an affected system show evidence of this issue?
With SLUB per-CPU sheaves batching kfree_rcu(), the issue can appear as a KASAN invalid-free report in rcu_free_sheaf().