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: <4b793236-2008-e57f-3257-48a65dae5d8b@oss.qualcomm.com>
Date: Tue, 9 Dec 2025 10:32:06 +0530
From: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@....qualcomm.com>
To: Alexandru Gagniuc <mr.nuke.me@...il.com>, jjohnson@...nel.org,
        ath11k@...ts.infradead.org, "Rob Herring (Arm)" <robh@...nel.org>
Cc: linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, Jeff Johnson <jeff.johnson@....qualcomm.com>
Subject: Re: [PATCH] wifi: ath11k: fix qmi memory allocation logic for CALDB
 region



On 12/8/2025 3:55 PM, Vasanthakumar Thiagarajan wrote:
> 
> 
> On 12/8/2025 3:38 PM, Vasanthakumar Thiagarajan wrote:
>>
>>
>> On 12/6/2025 11:28 PM, Alexandru Gagniuc wrote:
>>> Memory region assignment in ath11k_qmi_assign_target_mem_chunk()
>>> assumes that:
>>>    1. firmware will make a HOST_DDR_REGION_TYPE request, and
>>>    2. this request is processed before CALDB_MEM_REGION_TYPE
>>>
>>> In this case CALDB_MEM_REGION_TYPE, can safely be assigned immediately
>>> after the host region.
>>>
>>> However, if the HOST_DDR_REGION_TYPE request is not made, or the
>>
>> AFAICT, this is highly unlikely as HOST_DDR_REGION_TYPE will always be before
>> CALDB_MEM_REGION_TYPE. >
>>> reserved-memory node is not present, then res.start and res.end are 0,
>>> and host_ddr_sz remains uninitialized. The physical address should
>>> fall back to ATH11K_QMI_CALDB_ADDRESS. That doesn't happen:
>>>
>>> resource_size(&res) returns 1 for an empty resource, and thus the if
>>> clause never takes the fallback path. ab->qmi.target_mem[idx].paddr
>>> is assigned the uninitialized value of host_ddr_sz + 0 (res.start).
>>>
>>> Use "if (res.end > res.start)" for the predicate, which correctly
>>> falls back to ATH11K_QMI_CALDB_ADDRESS.
>>>
>>> Fixes: 900730dc4705 ("wifi: ath: Use of_reserved_mem_region_to_resource() for 
>>> "memory-region"")
>>>
>>> Cc: stable@...r.kernel.org # v6.18
>>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@...il.com>
>>> ---
>>>   drivers/net/wireless/ath/ath11k/qmi.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath11k/qmi.c b/drivers/net/wireless/ath/ath11k/qmi.c
>>> index aea56c38bf8f3..6cc26d1c1e2a4 100644
>>> --- a/drivers/net/wireless/ath/ath11k/qmi.c
>>> +++ b/drivers/net/wireless/ath/ath11k/qmi.c
>>> @@ -2054,7 +2054,7 @@ static int ath11k_qmi_assign_target_mem_chunk(struct ath11k_base 
>>> *ab)
>>>                   return ret;
>>>               }
>>> -            if (res.end - res.start + 1 < ab->qmi.target_mem[i].size) {
>>> +            if (resource_size(&res) < ab->qmi.target_mem[i].size) {
>>>                   ath11k_dbg(ab, ATH11K_DBG_QMI,
>>>                          "fail to assign memory of sz\n");
>>>                   return -EINVAL;
>>> @@ -2086,7 +2086,7 @@ static int ath11k_qmi_assign_target_mem_chunk(struct ath11k_base 
>>> *ab)
>>>               }
>>>               if (ath11k_core_coldboot_cal_support(ab)) {
>>> -                if (resource_size(&res)) {
>>> +                if (res.end > res.start) {
>>>                       ab->qmi.target_mem[idx].paddr =
>>>                               res.start + host_ddr_sz;
>>>                       ab->qmi.target_mem[idx].iaddr =
>>
>> The rest looks good.
>>
>> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@....qualcomm.com>
>>
> 
> Well, since CALDB_MEM_REGION_TYPE will always come only after HOST_DDR_REGION_TYPE we'll 
> not be running into this issue in real deployment with ath11k firmware binaries available 
> in public.
> 

Nevertheless, I agree this is a critical issue to be fixed. There is another patch[1]
fixing the same issue a bit differently.


Vasanth

[1]: https://lore.kernel.org/linux-wireless/20251208200437.14199-1-ansuelsmth@gmail.com/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ