linux-kernel - Re: [PATCH ath-next v2] wifi: ath12k: handle regulatory hints during mac registration

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: <a7626e7b-6308-c4d0-8d0a-0d80914841a0@oss.qualcomm.com>
Date: Thu, 19 Jun 2025 20:45:57 +0530
From: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@....qualcomm.com>
To: Aditya Kumar Singh <aditya.kumar.singh@....qualcomm.com>,
        Jeff Johnson <jjohnson@...nel.org>
Cc: linux-wireless@...r.kernel.org, ath12k@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH ath-next v2] wifi: ath12k: handle regulatory hints during
 mac registration



On 6/17/2025 9:05 AM, Aditya Kumar Singh wrote:
> If a regulatory notification is there in the system while the hardware is
> being registered, it attempts to set the new regulatory country. However,
> ath12k currently boots with a default country derived from the BDF. If this
> default country differs from the one provided in the notification, a race
> condition can occur while updating the regulatory information back to
> userspace. This potentially leads to driver having the incorrect regulatory
> applied.
> 
> For example, suppose the regulatory domain for France (FR) is already
> applied, and then the driver is loaded with a BDF that has the United
> States (US) country programmed. When the driver finishes loading, the
> regulatory domain shown in phyX still reflects the US regulatory settings.
> This is incorrect, as the driver had already received a notification for
> FR during hardware registration, but failed to process it properly due to
> the race condition.
> 
> The race condition exists during driver initialization and hardware
> registration:
> - On driver load, the firmware sends BDF-based country regulatory rules,
>    which are stored in default_regd via ath12k_reg_handle_chan_list().
> 
> - During hardware registration, a regulatory notification is triggered
>    through:
>      ath12k_mac_hw_register()
>        -> ieee80211_register_hw()
>          -> wiphy_register()
>            -> wiphy_regulatory_register()
>              -> reg_call_notifier()
> 
>    This sends a country code to the firmware, which responds with updated
>    regulatory rules.
> 
> - After registration, ath12k_mac_hw_register() calls ath12k_regd_update(),
>    which copies default_regd and passes it to the upper layers.
> 
> The race occurs between the firmware's response and the execution of
> ath12k_regd_update(). If the firmware's new rules are processed before the
> update call, the correct values are used. Otherwise, outdated boot-time
> country settings are exposed to userspace.
> 
> To resolve this issue, introduce a completion mechanism within the hardware
> group (ah). Trigger this completion whenever a regulatory change is
> requested from the firmware. Then, in ath12k_regd_update(), wait for the
> firmware to complete its regulatory processing before proceeding with the
> update.
> 
> This ensures that during driver load, the default country is processed
> first. However, before ath12k_regd_update() is called, the new regulatory
> notification will have already been received by the driver. As a result, it
> will wait for the firmware's regulatory processing to complete, and only
> the final, correct regulatory domain will be updated to userspace.
> 
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
> 
> Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@....qualcomm.com>

Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@....qualcomm.com>