---
id: CVE-2026-43401
title: >-
  cpufreq: intel_pstate: Fix NULL pointer dereference in
  update_cpu_qos_request()
summary: >-
  In the Linux kernel, the following vulnerability has been resolved:


  cpufreq: intel_pstate: Fix NULL pointer dereference in
  update_cpu_qos_request()


  The update_cpu_qos_request() function attempts to initialize the 'freq'

  variable by der…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= ae1bdd23b99f64335c69d546bff99ca39b894c18 <
    6bfda7ce56e7d14a677b7bcd6c7a5009cc29aa88
  - >-
    Linux >= ae1bdd23b99f64335c69d546bff99ca39b894c18 <
    42738dffb7b0766a45882dff7989401d78f66f92
  - >-
    Linux >= ae1bdd23b99f64335c69d546bff99ca39b894c18 <
    ab39cc4cb8ceecdc2b61747433e7237f1ac2b789
  - Linux 6.18
ssvc:
  exploitation: none
  automatable: 'no'
  technicalImpact: partial
  timestamp: '2026-11-06T15:37:22.098518Z'
published: '2026-05-08'
updated: '2026-11-06'
sourceUpdated: '2026-11-06T15:42:51.950Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-43401'
references:
  - url: 'https://git.kernel.org/stable/c/6bfda7ce56e7d14a677b7bcd6c7a5009cc29aa88'
  - url: 'https://git.kernel.org/stable/c/42738dffb7b0766a45882dff7989401d78f66f92'
  - url: 'https://git.kernel.org/stable/c/ab39cc4cb8ceecdc2b61747433e7237f1ac2b789'
tags:
  - cve.org
epss: 0.00121
epssPercentile: 0.01903
ingestedAt: '2026-11-06T15:54:03.925Z'
---

## Overview

In the Linux kernel, the following vulnerability has been resolved:

cpufreq: intel_pstate: Fix NULL pointer dereference in update_cpu_qos_request()

The update_cpu_qos_request() function attempts to initialize the 'freq'
variable by dereferencing 'cpudata' before verifying if the 'policy'
is valid.

This issue occurs on systems booted with the "nosmt" parameter, where
all_cpu_data[cpu] is NULL for the SMT sibling threads. As a result,
any call to update_qos_requests() will result in a NULL pointer
dereference as the code will attempt to access pstate.turbo_freq using
the NULL cpudata pointer.

Also, pstate.turbo_freq may be updated by intel_pstate_get_hwp_cap()
after initializing the 'freq' variable, so it is better to defer the
'freq' until intel_pstate_get_hwp_cap() has been called.

Fix this by deferring the 'freq' assignment until after the policy and
driver_data have been validated.

[ rjw: Added one paragraph to the changelog ]

## Affected

- `Linux >= ae1bdd23b99f64335c69d546bff99ca39b894c18 < 6bfda7ce56e7d14a677b7bcd6c7a5009cc29aa88`
- `Linux >= ae1bdd23b99f64335c69d546bff99ca39b894c18 < 42738dffb7b0766a45882dff7989401d78f66f92`
- `Linux >= ae1bdd23b99f64335c69d546bff99ca39b894c18 < ab39cc4cb8ceecdc2b61747433e7237f1ac2b789`
- `Linux 6.18`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.