Skip to main content
cve.nowby Sazabi
← All vulnerabilities
CVE-2026-52923

ipc: limit next_id allocation to the valid ID range

Published
Last modified
published
Not listed in CISA KEV
Fix
Fixed in 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, and 2 more
None on Exploit-DB, Metasploit or GitHub
  • Exploitation: none
  • Automatable: no
  • Technical impact: total

Summary

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.

Timeline

  1. CVE published
  2. CISA SSVC assessment

    Exploitation: none · Automatable: no · Technical impact: total

  3. Record last updated

Affected versions

  • Linux Linux

    From 03f595668017f1a1fb971c02fc37140bc6e7bb1c · fixed in 3bbe2bb9111ce6967a951bfac79af142d816fae5; From 03f595668017f1a1fb971c02fc37140bc6e7bb1c · fixed in 8c58a92849175f5e2ab7bc2734b3b89afe79f6ef; From 03f595668017f1a1fb971c02fc37140bc6e7bb1c · fixed in af24e202b543ded8a34f1d5d3db54eb916173f04; From 03f595668017f1a1fb971c02fc37140bc6e7bb1c · fixed in 157ce2c6836ce0ff19108a819f38df061345425f; From 03f595668017f1a1fb971c02fc37140bc6e7bb1c · fixed in 41058d4c3f63ab64901560a704882e0565f4e456; From 03f595668017f1a1fb971c02fc37140bc6e7bb1c · fixed in a3cc795129e5ec0f8948653a3bf471e7d8852f5e; From 03f595668017f1a1fb971c02fc37140bc6e7bb1c · fixed in bd4be70669af55b974860d13680348cfdf50bbed; From 03f595668017f1a1fb971c02fc37140bc6e7bb1c · fixed in fa0b9b2b7ae3539908d69c2b9ac0d144d9bc5139

  • Linux Linux

    3.8

  • KernelLinux

    From 3.8.0 · fixed in 5.10.259; From 5.11.0 · fixed in 5.15.210; From 5.16.0 · fixed in 6.1.176; From 6.2.0 · fixed in 6.6.143; From 6.7.0 · fixed in 6.12.93; From 6.13.0 · fixed in 6.18.35; From 6.19.0 · fixed in 7.0.12

References 8

git.kernel.org