CVE-2026-43328

What it actually does

This is a Linux kernel memory-management flaw in the CPU frequency governor initialization error path. If kobject_init_and_add() fails after the governor data structure has been associated with a kobject, cleanup is performed through kobject_put(), whose release callback frees the governor data. The vulnerable path then attempts to call the governor exit routine and free the same memory again, creating a double-free condition. In kernel space, a double free can corrupt allocator metadata or cause reuse of freed memory, potentially leading to kernel crash, denial of service, or, if an attacker can reliably shape heap state and trigger the failure path, local privilege escalation with kernel-level code execution. The CVSS vector indicates local access with low privileges and no user interaction, but there is no known public exploit maturity and EPSS is currently low.

Why it matters to the business

Successful exploitation could allow a local user or process on an affected Linux system to crash the host or potentially gain elevated privileges, which could affect workload availability, tenant isolation, and integrity of sensitive data. The operational risk is highest for shared Linux servers, developer workstations, container hosts, virtualization hosts, and systems where untrusted local users or workloads can influence kernel interfaces. This issue is not listed in CISA KEV and is not known to be used in ransomware campaigns, and the current EPSS score is low, but kernel memory-corruption flaws should still be prioritized because a reliable exploit can have full system impact.

How an attack unfolds

An attacker first needs local code execution or an account on an affected Linux system. They then attempt to reach CPU frequency governor initialization logic, typically through kernel CPU frequency management interfaces or by influencing governor loading, switching, or initialization behavior. The vulnerable condition requires kobject_init_and_add() to fail after the governor data object has been initialized, which may require resource pressure, race timing, fault conditions, or a specially shaped system state. When the failure occurs, the kernel calls kobject_put(), which invokes the release path and frees the governor data. The vulnerable error path then frees the same object again. In a simple case, this causes a kernel panic or allocator corruption and results in denial of service. In a more advanced exploit, the attacker would attempt to reclaim the freed memory with controlled kernel objects before the second free or subsequent use, with the goal of corrupting kernel memory and escalating privileges.

How to fix it

Upgrade the Linux kernel to a vendor-provided version that contains the fix for the cpufreq governor double-free in cpufreq_dbs_governor_init(). No exact fixed package versions were provided in the input, so use the fixed kernel builds published by the relevant Linux distribution, appliance vendor, cloud image provider, or embedded platform vendor. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, enforcing least privilege, disabling unnecessary CPU frequency governor modules or interfaces where operationally safe, and preventing unauthorized writes to CPU frequency sysfs controls. Because this is kernel code, full remediation generally requires installing the patched kernel and rebooting into it.

How to confirm the fix worked

Confirm that systems are running a kernel build that includes the upstream or vendor backport for the cpufreq_dbs_governor_init() cleanup fix. Validate by checking the active kernel version after reboot with standard OS tooling such as uname -a and comparing it to the distribution vendor advisory or package changelog. Review installed kernel package metadata to ensure the patched kernel is installed and currently booted, not merely downloaded. If source validation is available, confirm that after kobject_init_and_add() is called, the error path relies on kobject_put() and does not directly call the governor exit routine and kfree(dbs_data) a second time. Also verify that CPU frequency scaling continues to operate normally and that no kernel warnings, KASAN reports, or cpufreq governor initialization errors appear after the update.

Typical attack path

1. Obtain local access to an affected Linux system as a low-privileged user or through a compromised local workload.
2. Identify whether CPU frequency scaling and affected governors are present and usable on the system.
3. Attempt to trigger CPU frequency governor initialization or switching behavior that reaches cpufreq_dbs_governor_init().
4. Induce or wait for a kobject_init_and_add() failure condition, such as resource exhaustion or a controlled initialization failure scenario.
5. Trigger the vulnerable cleanup path where kobject_put() releases the governor data and the error path frees it again.
6. Use the double-free condition to crash the kernel or, with a reliable heap manipulation technique, attempt local privilege escalation.

How to detect it

Look for evidence of attempted or successful triggering of the cpufreq governor initialization error path and resulting kernel memory corruption. Useful log sources include dmesg, journald kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore artifacts, audit logs for writes to CPU frequency sysfs paths, and EDR telemetry for local processes repeatedly interacting with /sys/devices/system/cpu/. Search for kernel oops, panic, slab allocator, KASAN, KFENCE, or UBSAN reports mentioning double free, use-after-free, kobject cleanup, cpufreq, dbs governor data, or cpufreq_dbs_governor_init(). Also review unusual local activity preceding a crash, such as repeated writes to scaling_governor, attempts to load or unload cpufreq-related modules, resource-exhaustion behavior intended to force allocation or kobject registration failure, and process activity from untrusted users around the time of kernel faults. Because no public exploit or campaign is known from the provided data, detection should focus on anomalous local triggering patterns and kernel memory-corruption artifacts rather than fixed network indicators.

• BUG: KASAN: double-free
• KASAN: double-free
• double free detected
• kernel BUG at
• general protection fault
• Oops:
• Kernel panic - not syncing
• cpufreq_dbs_governor_init
• cpufreq_dbs_data_release
• kobject_init_and_add
• kobject_put
• dbs_data
• cpufreq: governor
• /sys/devices/system/cpu/cpufreq
• /sys/devices/system/cpu/cpufreq/policy
• scaling_governor
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /proc/vmcore

What your security team should do

• Inventory Linux systems, especially shared servers, container hosts, virtualization hosts, developer systems, and systems allowing local user access.
• Track vendor advisories for the affected Linux kernel packages and prioritize applying patched kernels through normal emergency or high-priority kernel maintenance processes.
• Reboot systems after kernel update and verify the patched kernel is the active running kernel.
• Prioritize systems where untrusted users, CI jobs, containers, or third-party workloads have local execution capability.
• If patching is delayed, restrict local interactive access, harden container boundaries, and limit access to CPU frequency governor controls under /sys/devices/system/cpu/.
• Enable and monitor kernel crash, panic, and memory-corruption telemetry, including journald, dmesg, syslog, audit logs, and kernel oops collection.
• Investigate any recent unexplained kernel panics or KASAN double-free reports involving cpufreq, kobject, or governor initialization.
• Do not treat the low EPSS score as a reason to ignore the issue on multi-user or high-value Linux systems, because successful kernel exploitation can provide full host compromise.