Linux Kernel: IPC ID Allocation Out of Bounds Causes IDR Corruption
CVE-2026-52923 Published on June 24, 2026

ipc: limit next_id allocation to the valid ID range
In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.

NVD

Vulnerability Analysis

CVE-2026-52923 can be exploited with local system access, and requires small amount of user privileges. This vulnerability is consided to have a high level of attack complexity. The potential impact of an exploit of this vulnerability is considered to have a small impact on confidentiality and integrity, and a high impact on availability.

Attack Vector:
LOCAL
Attack Complexity:
HIGH
Privileges Required:
LOW
User Interaction:
NONE
Scope:
UNCHANGED
Confidentiality Impact:
LOW
Integrity Impact:
LOW
Availability Impact:
HIGH

Weakness Type

What is a Dangling pointer Vulnerability?

The program dereferences a pointer that contains a location for memory that was previously valid, but is no longer valid. When a program releases memory, but it maintains a pointer to that memory, then the memory might be re-allocated at a later time. If the original pointer is accessed to read or write data, then this could cause the program to read or modify data that is in use by a different function or process. Depending on how the newly-allocated memory is used, this could lead to a denial of service, information exposure, or code execution.

CVE-2026-52923 has been classified to as a Dangling pointer vulnerability or weakness.


Products Associated with CVE-2026-52923

You can be notified by email with stack.watch whenever vulnerabilities like CVE-2026-52923 are published in these products:

 
 
 
 
 
 
 

Affected Versions

Linux: Linux: Red Hat Enterprise Linux 8: Red Hat Enterprise Linux 8: Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support: Red Hat Enterprise Linux 8.4 Extended Update Support Long-Life Add-On: Red Hat Enterprise Linux 9: Red Hat Enterprise Linux 9.4 Update Services for SAP Solutions: Red Hat Enterprise Linux 9.6 Extended Update Support: Red Hat Enterprise Linux 10: Red Hat Enterprise Linux 6: Red Hat Enterprise Linux 7: Red Hat Enterprise Linux 7: Red Hat Enterprise Linux 9:

Exploit Probability

EPSS
0.13%
Percentile
2.98%

EPSS (Exploit Prediction Scoring System) scores estimate the probability that a vulnerability will be exploited in the wild within the next 30 days. The percentile shows you how this score compares to all other vulnerabilities.