Bug 2502341 (CVE-2026-64027) - CVE-2026-64027 kernel: net: shaper: rework the VALID marking (again)
Summary: CVE-2026-64027 kernel: net: shaper: rework the VALID marking (again)
Keywords:
Status: NEW
Alias: CVE-2026-64027
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-07-19 16:02 UTC by OSIDB Bzimport
Modified: 2026-09-07 10:10 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-07-19 16:02:51 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.