Answer in brief
CVE-2026-64377 records a Unknown severity vulnerability in cpufreq: qcom-cpufreq-hw: Fix possible double free. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=054a3ef683a176a509cc9b37f762029aae942495 <28a03a3f6e6cda0b0da3b43761d175dec5d14d13 || >=054a3ef683a176a509cc9b37f762029aae942495 <e904961332801c87355f5d11c65bb433e717c489 || >=054a3ef683a176a509cc9b37f762029aae942495 <9de568ef6cdfc7912d5ea8db02843c0e4ef0c75d || >=054a3ef683a176a509cc9b37f762029aae942495 <bcb8889c4981fdde42d4fd2c29a77d510fe21da2 | 28a03a3f6e6cda0b0da3b43761d175dec5d14d13, e904961332801c87355f5d11c65bb433e717c489, 9de568ef6cdfc7912d5ea8db02843c0e4ef0c75d, bcb8889c4981fdde42d4fd2c29a77d510fe21da2 |
| Linux/Linuxgeneric | 6.2 | Not reported |
Published upstream
Jul 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 11, 2026
In the Linux kernel, the following vulnerability has been resolved: cpufreq: qcom-cpufreq-hw: Fix possible double free qcom_cpufreq.data is allocated with devm_kzalloc() in probe() as an array of per-domain data. qcom_cpufreq_hw_cpu_init() stores a pointer to one element of this array in policy->driver_data. qcom_cpufreq_hw_cpu_exit() currently calls kfree() on policy->driver_data. This is not valid because the memory is devm-managed. For the first domain, this can free the devm-managed allocation while the devres entry is still active, leading to a possible double free when the platform device is later detached. For other domains, the pointer may refer to an element inside the array rather than the allocation base. Remove the kfree(data) call and let devres release qcom_cpufreq.data. This issue was found by a static analysis tool I am developing.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-64377 records a Unknown severity vulnerability in cpufreq: qcom-cpufreq-hw: Fix possible double free. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=054a3ef683a176a509cc9b37f762029aae942495 <28a03a3f6e6cda0b0da3b43761d175dec5d14d13 || >=054a3ef683a176a509cc9b37f762029aae942495 <e904961332801c87355f5d11c65bb433e717c489 || >=054a3ef683a176a509cc9b37f762029aae942495 <9de568ef6cdfc7912d5ea8db02843c0e4ef0c75d || >=054a3ef683a176a509cc9b37f762029aae942495 <bcb8889c4981fdde42d4fd2c29a77d510fe21da2 | 28a03a3f6e6cda0b0da3b43761d175dec5d14d13, e904961332801c87355f5d11c65bb433e717c489, 9de568ef6cdfc7912d5ea8db02843c0e4ef0c75d, bcb8889c4981fdde42d4fd2c29a77d510fe21da2 |
| Linux/Linuxgeneric | 6.2 | Not reported |
Published upstream
Jul 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 11, 2026
In the Linux kernel, the following vulnerability has been resolved: cpufreq: qcom-cpufreq-hw: Fix possible double free qcom_cpufreq.data is allocated with devm_kzalloc() in probe() as an array of per-domain data. qcom_cpufreq_hw_cpu_init() stores a pointer to one element of this array in policy->driver_data. qcom_cpufreq_hw_cpu_exit() currently calls kfree() on policy->driver_data. This is not valid because the memory is devm-managed. For the first domain, this can free the devm-managed allocation while the devres entry is still active, leading to a possible double free when the platform device is later detached. For other domains, the pointer may refer to an element inside the array rather than the allocation base. Remove the kfree(data) call and let devres release qcom_cpufreq.data. This issue was found by a static analysis tool I am developing.
Quoted source text, attributed separately from HOL analysis.