Cloudanix VulnDB

CVE-2025-38675

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Aug 22, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing problem in the Linux kernel's network security code could let an attacker interfere with protected connections and cause systems to crash or behave unexpectedly.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Other
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in xfrm_state_find allows preemption to cause xfrm_state_look_at to select a mismatched per-CPU state; the subsequent jump to the acquire block then uses the uninitialized state_ptrs variable.

Why it matters to the business

Kernel instability or unexpected behavior in IPsec-protected network traffic on Linux systems can produce outages or require unplanned reboots; widespread kernel exposure increases operational risk for any organization running affected versions.

How an attack unfolds

An attacker triggers concurrent xfrm state lookups while the system is under preemption; the resulting mismatched CPU context causes the acquire path to dereference an uninitialized pointer, leading to a crash or undefined kernel state.

How to fix it

Upgrade the Linux kernel to 6.12.41 or later (or the exact commit 6bf2daafc51bcb9272c0fdff2afd38217337d0d3). For Chainguard packages, update to openjdk-17-openj9 0.53.0-r0 or newer. Reboot after kernel updates and verify the running kernel version.

How to confirm the fix worked

Confirm the installed kernel version is at least 6.12.41, check dmesg or kernel logs for the resolved xfrm_state_find initialization change, and run regression tests that exercise xfrm state lookups under load.

Typical attack path

  1. Establish network conditions that cause repeated xfrm_state_find calls
  2. Force preemption between rcu_read_lock and the state lookup
  3. Trigger the mismatched per-CPU state match and jump to the acquire block
  4. Observe kernel panic or memory corruption from the uninitialized state_ptrs use

How to detect it

Review kernel crash dumps and dmesg for xfrm_state_find or state_ptrs related oopses; correlate with network events that involve IPsec SA creation under high preemption load.

What your security team should do

  • Prioritize kernel upgrades on all internet-facing or IPsec-using systems within the next maintenance window
  • Apply the listed fixed package versions for Chainguard OpenJDK environments
  • Monitor EPSS and KEV feeds for any future increase in exploit activity
  • Schedule staged rollouts and kernel-version validation across fleets

The record

In the Linux kernel, the following vulnerability has been resolved: xfrm: state: initialize state_ptrs earlier in xfrm_state_find In case of preemption, xfrm_state_look_at will find a different pcpu_id and look up states for that other CPU. If we matched a state for CPU2 in the state_cache while the lookup started on CPU1, we will jump to "found", but the "best" state that we got will be ignored and we will enter the "acquire" block. This block uses state_ptrs, which isn't initialized at this point. Let's initialize state_ptrs just after taking rcu_read_lock. This will also prevent a possible misuse in the future, if someone adjusts this function.

Affected packages

Ecosystem Package Introduced Fixed
Debian:13 linux 0 6.12.41-1
Debian:14 linux 0 No fix
Debian:14 linux 0 6.16.3-1
Linux Kernel 0 6.12.41

Related vulnerabilities