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

net: shaper: rework the VALID marking (again)

Recent commit changed the semantics from NOT_VALID to VALID.
I didn't realize that the flags are not stored atomically
with the entry in XArray. There's still a race of reader
observing a VALID mark for a slot, getting interrupted,
writer replacing the entry with a different one, reader
continuing, fetching the entry which is now a different
pointer than the pointer for which VALID was meant.

The biggest consequence of this is that we may see a UAF
since net_shaper_rollback() assumed that entries without
VALID can be freed without observing RCU.

Looks like the XArray marks are buying us nothing at this
point. Let's convert the code to an explicit valid field.
The smp_load_acquire() / smp_store_release() barriers are
marginally cleaner.
Published: 2026-07-19
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

In the Linux kernel network shaper, the VALID flag on an XArray entry is set and cleared without atomicity, creating a race between a reader that observes a VALID mark and a writer that replaces the entry. If a reader continues after being interrupted and then fetches a different pointer that was not originally associated with the VALID stamp, the rollback routine may free memory that has already been reallocated. This use‑after‑free can corrupt kernel memory. The description explicitly notes that the biggest consequence is a UAF, which is the primary impact.

Affected Systems

All Linux kernel releases that contain the shaper subsystem before the commit that introduces an explicit atomic VALID field are affected. The referenced commits (2417df5e7bb4184b9d3a2988036bf2c46e594545, 96ea960dd40fd55302e0fd755176f26a95e6a50c, b8d7519352ba8c6df83259295d4a3bad093cae90) provide the fix, so kernel versions prior to those changes are vulnerable. This includes all standard and distribution kernels that have not applied the patch.

Risk and Exploitability

The CVSS score of 7.8 indicates a high severity. The EPSS score of less than 1% implies an extremely low measured probability of exploitation at the time of analysis, and the vulnerability is not listed in the CISA KEV catalog. Exploitation would require an attacker able to trigger the race condition, likely by manipulating traffic shaping operations or inducing specific timing scenarios. The combination of a race condition, non‑atomic flag handling, and reliance on RCU suggests that the window for successful exploitation is narrow and requires precise conditions, which aligns with the low EPSS.

Generated by OpenCVE AI on August 4, 2026 at 06:10 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a kernel update that contains the commit converting the VALID marking to an explicit atomic field
  • If an update is unavailable, disable or restrict use of the network shaper subsystem to mitigate the race window
  • For custom or older kernel builds, backport the upstream commit that introduces the atomic VALID field

Generated by OpenCVE AI on August 4, 2026 at 06:10 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Ubuntu USN Ubuntu USN USN-8593-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8603-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8618-1 Linux kernel vulnerabilities
History

Sun, 26 Jul 2026 08:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-416

Wed, 22 Jul 2026 18:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-416

Wed, 22 Jul 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-367
References
Metrics threat_severity

None

threat_severity

Moderate


Mon, 20 Jul 2026 14:45:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Sun, 19 Jul 2026 15:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: net: shaper: rework the VALID marking (again) Recent commit changed the semantics from NOT_VALID to VALID. I didn't realize that the flags are not stored atomically with the entry in XArray. There's still a race of reader observing a VALID mark for a slot, getting interrupted, writer replacing the entry with a different one, reader continuing, fetching the entry which is now a different pointer than the pointer for which VALID was meant. The biggest consequence of this is that we may see a UAF since net_shaper_rollback() assumed that entries without VALID can be freed without observing RCU. Looks like the XArray marks are buying us nothing at this point. Let's convert the code to an explicit valid field. The smp_load_acquire() / smp_store_release() barriers are marginally cleaner.
Title net: shaper: rework the VALID marking (again)
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-05T12:38:22.063Z

Reserved: 2026-07-19T07:54:57.028Z

Link: CVE-2026-64027

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-07-19T00:00:00Z

Links: CVE-2026-64027 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-04T06:15:04Z

Weaknesses
  • CWE-367

    Time-of-check Time-of-use (TOCTOU) Race Condition