From: Dongliang Mu <hidden> Date: 2021-07-23 05:09:53
The commit beee24695157 ("cfg80211: Save the regulatory domain when
setting custom regulatory") forgets to free the newly allocated regd
object.
Fix this by freeing the regd object in the error handling code and
deletion function - mac80211_hwsim_del_radio.
Reported-by: syzbot+1638e7c770eef6b6c0d0@syzkaller.appspotmail.com
Fixes: beee24695157 ("cfg80211: Save the regulatory domain when setting custom regulatory")
Signed-off-by: Dongliang Mu <redacted>
---
drivers/net/wireless/mac80211_hwsim.c | 4 ++++
1 file changed, 4 insertions(+)
From: Dongliang Mu <hidden> Date: 2021-07-23 05:17:18
On Fri, Jul 23, 2021 at 1:09 PM Dongliang Mu [off-list ref] wrote:
quoted hunk
The commit beee24695157 ("cfg80211: Save the regulatory domain when
setting custom regulatory") forgets to free the newly allocated regd
object.
Fix this by freeing the regd object in the error handling code and
deletion function - mac80211_hwsim_del_radio.
Reported-by: syzbot+1638e7c770eef6b6c0d0@syzkaller.appspotmail.com
Fixes: beee24695157 ("cfg80211: Save the regulatory domain when setting custom regulatory")
Signed-off-by: Dongliang Mu <redacted>
---
drivers/net/wireless/mac80211_hwsim.c | 4 ++++
1 file changed, 4 insertions(+)
@@ -3404,6 +3404,8 @@ static int mac80211_hwsim_new_radio(struct genl_info *info,debugfs_remove_recursive(data->debugfs);ieee80211_unregister_hw(data->hw);failed_hw:+if(param->regd)+kfree_rcu(get_wiphy_regdom(data->hw->wiphy));
Here kfree_rcu supports only 1 parameter. But some example code uses
the 2nd parameter: rcu_head or rcu. For example,
static void rcu_free_regdom(const struct ieee80211_regdomain *r)
{
......
kfree_rcu((struct ieee80211_regdomain *)r, rcu_head);
}
If this patch has any issues, please let me know.
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-07-23 08:38:05
On Fri, 2021-07-23 at 13:09 +0800, Dongliang Mu wrote:
The commit beee24695157 ("cfg80211: Save the regulatory domain when
setting custom regulatory") forgets to free the newly allocated regd
object.
Not really? It's not forgetting it, it just saves it?
+ new_regd = reg_copy_regd(regd);
+ if (IS_ERR(new_regd))
+ return;
+
+ tmp = get_wiphy_regdom(wiphy);
+ rcu_assign_pointer(wiphy->regd, new_regd);
+ rcu_free_regdom(tmp);
Fix this by freeing the regd object in the error handling code and
deletion function - mac80211_hwsim_del_radio.
This can't be right - the same would affect all other users of that
function, no?
Perhaps somewhere we have a case where wiphy->regd is leaked, but than
that should be fixed more generally in cfg80211?
johannes
From: Dongliang Mu <hidden> Date: 2021-07-23 09:14:33
On Fri, Jul 23, 2021 at 4:37 PM Johannes Berg [off-list ref] wrote:
On Fri, 2021-07-23 at 13:09 +0800, Dongliang Mu wrote:
quoted
The commit beee24695157 ("cfg80211: Save the regulatory domain when
setting custom regulatory") forgets to free the newly allocated regd
object.
Not really? It's not forgetting it, it just saves it?
Yes, it saves the regd object in the function wiphy_apply_custom_regulatory.
But its parent function - mac80211_hwsim_new_radio forgets to free
this object when the ieee80211_register_hw fails.
Fix this by freeing the regd object in the error handling code and
deletion function - mac80211_hwsim_del_radio.
This can't be right - the same would affect all other users of that
function, no?
The problem occurs in the error handling code of
mac80211_hwsim_new_radio, not wiphy_apply_custom_regulatory. My commit
message may be not very clear.
So I think the code in the mac80211_hwsim_del_radio paired with
mac80211_hwsim_new_radio should be changed correspondingly. If I miss
any problems, please let me know.
I have successfully tested my patch in the syzbot dashboard [1].
[1] https://syzkaller.appspot.com/bug?extid=1638e7c770eef6b6c0d0
Perhaps somewhere we have a case where wiphy->regd is leaked, but than
that should be fixed more generally in cfg80211?
johannes
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-07-23 09:18:26
On Fri, 2021-07-23 at 17:13 +0800, Dongliang Mu wrote:
On Fri, Jul 23, 2021 at 4:37 PM Johannes Berg [off-list ref] wrote:
quoted
On Fri, 2021-07-23 at 13:09 +0800, Dongliang Mu wrote:
quoted
The commit beee24695157 ("cfg80211: Save the regulatory domain when
setting custom regulatory") forgets to free the newly allocated regd
object.
Not really? It's not forgetting it, it just saves it?
Yes, it saves the regd object in the function wiphy_apply_custom_regulatory.
Right.
But its parent function - mac80211_hwsim_new_radio forgets to free
this object when the ieee80211_register_hw fails.
But why is this specific to mac80211-hwsim?
Any other code calling wiphy_apply_custom_regulatory() and then failing
the subsequent wiphy_register() or otherwise calling wiphy_free() will
run into the same situation.
So why wouldn't we free this in wiphy_free(), if it exists?
johannes
The commit beee24695157 ("cfg80211: Save the regulatory domain when
setting custom regulatory") forgets to free the newly allocated regd
object.
Fix this by freeing the regd object in the error handling code and
deletion function - mac80211_hwsim_del_radio.
Reported-by: syzbot+1638e7c770eef6b6c0d0@syzkaller.appspotmail.com
Fixes: beee24695157 ("cfg80211: Save the regulatory domain when setting custom regulatory")
Signed-off-by: Dongliang Mu <redacted>
---
drivers/net/wireless/mac80211_hwsim.c | 4 ++++
1 file changed, 4 insertions(+)
From: Dongliang Mu <hidden> Date: 2021-07-23 09:26:02
On Fri, Jul 23, 2021 at 5:18 PM xiaoqiang zhao
[off-list ref] wrote:
在 2021/7/23 13:09, Dongliang Mu 写道:
quoted
The commit beee24695157 ("cfg80211: Save the regulatory domain when
setting custom regulatory") forgets to free the newly allocated regd
object.
Fix this by freeing the regd object in the error handling code and
deletion function - mac80211_hwsim_del_radio.
Reported-by: syzbot+1638e7c770eef6b6c0d0@syzkaller.appspotmail.com
Fixes: beee24695157 ("cfg80211: Save the regulatory domain when setting custom regulatory")
Signed-off-by: Dongliang Mu <redacted>
---
drivers/net/wireless/mac80211_hwsim.c | 4 ++++
1 file changed, 4 insertions(+)
From: Dongliang Mu <hidden> Date: 2021-07-23 09:31:19
On Fri, Jul 23, 2021 at 5:18 PM Johannes Berg [off-list ref] wrote:
On Fri, 2021-07-23 at 17:13 +0800, Dongliang Mu wrote:
quoted
On Fri, Jul 23, 2021 at 4:37 PM Johannes Berg [off-list ref] wrote:
quoted
On Fri, 2021-07-23 at 13:09 +0800, Dongliang Mu wrote:
quoted
The commit beee24695157 ("cfg80211: Save the regulatory domain when
setting custom regulatory") forgets to free the newly allocated regd
object.
Not really? It's not forgetting it, it just saves it?
Yes, it saves the regd object in the function wiphy_apply_custom_regulatory.
Right.
quoted
But its parent function - mac80211_hwsim_new_radio forgets to free
this object when the ieee80211_register_hw fails.
But why is this specific to mac80211-hwsim?
Any other code calling wiphy_apply_custom_regulatory() and then failing
the subsequent wiphy_register() or otherwise calling wiphy_free() will
run into the same situation.
So why wouldn't we free this in wiphy_free(), if it exists?
Hi Johannes,
if zhao in the thread is right, we don't need to add this free
operation to wiphy_free().
What we should do is to only handle regd in the error handling code of
mac80211_hwsim_new_radio. This will not affect other users of
mac80211-hwsim. Any idea?
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-07-23 09:42:52
Hi,
On Fri, 2021-07-23 at 17:30 +0800, Dongliang Mu wrote:
if zhao in the thread is right, we don't need to add this free
operation to wiphy_free().
Actually, no, that statement is not true.
All that zhao claimed was that the free happens correctly during
unregister (or later), and that is indeed true, since it happens from
ieee80211_unregister_hw()
-> wiphy_unregister()
-> wiphy_regulatory_deregister()
However, syzbot of course is also correct. Abstracting a bit and
ignoring mac80211, the problem is that here we assign it before
wiphy_register(), then wiphy_register() doesn't get called or fails, and
therefore we don't call wiphy_unregister(), only wiphy_free().
Hence the leak.
But you can also easily see from that description that it's not related
to hwsim - we should add a secondary round of cleanups in wiphy_free()
or even move the call to wiphy_regulatory_deregister() into
wiphy_free(), we need to look what else this does to see if we can move
it or not.
johannes
From: Dongliang Mu <hidden> Date: 2021-07-23 10:00:17
On Fri, Jul 23, 2021 at 5:42 PM Johannes Berg [off-list ref] wrote:
Hi,
On Fri, 2021-07-23 at 17:30 +0800, Dongliang Mu wrote:
quoted
if zhao in the thread is right, we don't need to add this free
operation to wiphy_free().
Actually, no, that statement is not true.
All that zhao claimed was that the free happens correctly during
unregister (or later), and that is indeed true, since it happens from
ieee80211_unregister_hw()
-> wiphy_unregister()
-> wiphy_regulatory_deregister()
Thanks for your explanation. Now the situation is more clear.
However, syzbot of course is also correct. Abstracting a bit and
ignoring mac80211, the problem is that here we assign it before
wiphy_register(), then wiphy_register() doesn't get called or fails, and
therefore we don't call wiphy_unregister(), only wiphy_free().
Yes, you're right. In this case, wiphy_register is not called. We
should not call wiphy_unregister() to clean up anything.
Hence the leak.
But you can also easily see from that description that it's not related
to hwsim - we should add a secondary round of cleanups in wiphy_free()
or even move the call to wiphy_regulatory_deregister() into
wiphy_free(), we need to look what else this does to see if we can move
it or not.
I agree to move the cleanup operation of regd to wiphy_free API.
That's the partial functionability of this function.