Linux Kernel up to 6.18.18/6.19.8 update_cpu_qos_request nosmt null pointer dereference

Summaryinfo

A vulnerability categorized as critical has been discovered in Linux Kernel up to 6.18.18/6.19.8. This vulnerability affects the function update_cpu_qos_request. The manipulation of the argument nosmt results in null pointer dereference. This vulnerability is cataloged as CVE-2026-43401. There is no exploit available. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability, which was classified as critical, was found in Linux Kernel up to 6.18.18/6.19.8. Affected is the function update_cpu_qos_request. The manipulation of the argument nosmt with an unknown input leads to a null pointer dereference vulnerability. CWE is classifying the issue as CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit. This is going to have an impact on availability. CVE summarizes:

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 ]

The advisory is shared for download at git.kernel.org. This vulnerability is traded as CVE-2026-43401 since 05/01/2026. There are known technical details, but no exploit is available.

Upgrading to version 6.18.19 or 6.19.9 eliminates this vulnerability. Applying the patch 6bfda7ce56e7d14a677b7bcd6c7a5009cc29aa88/42738dffb7b0766a45882dff7989401d78f66f92/ab39cc4cb8ceecdc2b61747433e7237f1ac2b789 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.18.0
• 6.18.1
• 6.18.2
• 6.18.3
• 6.18.4
• 6.18.5
• 6.18.6
• 6.18.7
• 6.18.8
• 6.18.9
• 6.18.10
• 6.18.11
• 6.18.12
• 6.18.13
• 6.18.14
• 6.18.15
• 6.18.16
• 6.18.17
• 6.18.18
• 6.19.0
• 6.19.1
• 6.19.2
• 6.19.3
• 6.19.4
• 6.19.5
• 6.19.6
• 6.19.7
• 6.19.8

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion