The Linux kernel’s System V shared memory subsystem contains a race condition involving the orphan cleanup routine. When a kernel walk removes orphaned segments, the check that decides whether a segment can be destroyed does not hold the lock protecting the attachment counter. Although the counter is updated while holding a separate object lock, the cleanup path runs without that protection, allowing the counter to change concurrently. This synchronization hole can cause the kernel to incorrectly deem a segment unused or in use, leading to premature deletion of active segments, loss of data, crashes, or memory leaks. Based on the description, it is inferred that the flaw itself does not rely on any external, untrusted input.

All Linux kernel builds that have not incorporated the patch found in commits 030bbc8, 1f0d01e, 2e5c6f4, 6560be3, 92cda25, b1e9aef, b5107b4, and db752eb are affected. The vulnerability is present in any Kernel release prior to these commits, regardless of distribution; it applies to the core `ipc/shm` implementation in the mainline kernel.

Based on the description, it is inferred that the attacker needs local or kernel-level privileges to create or attach to System V shared memory segments while the kernel is performing orphan cleanup. The flaw does not depend on untrusted input and requires a local process that can create or attach to System V shared memory segments while the kernel is performing orphan cleanup. Thus the attack surface is local (or a component with kernel privileges). No publicly known remote exploit or exploitation chain is documented, and the EPSS score is 0.00165. The vulnerability is not listed in the CISA KEV catalog. An attacker with sufficient local privileges could leverage the race to trigger memory corruption, crash services, or exhaust system resources, resulting in a denial of service. The CVSS score is 5.5.