<Vulnerability name="CVE-2026-52923">
    <DocumentDistribution xml:lang="en">Copyright © 2012 Red Hat, Inc. All rights reserved.</DocumentDistribution>
    <ThreatSeverity>Moderate</ThreatSeverity>
    <PublicDate>2026-06-24T00:00:00</PublicDate>
    <Bugzilla id="2492094" url="https://bugzilla.redhat.com/show_bug.cgi?id=2492094" xml:lang="en:us">
kernel: ipc: limit next_id allocation to the valid ID range
    </Bugzilla>
    <CVSS3 status="draft">
        <CVSS3BaseScore>5.8</CVSS3BaseScore>
        <CVSS3ScoringVector>CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H</CVSS3ScoringVector>
    </CVSS3>
    <CWE>CWE-825</CWE>
    <Details xml:lang="en:us" source="Mitre">
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-&gt;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-&gt;next_id is passed to:

       idr_alloc(&amp;ids-&gt;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-&gt;id = (new-&gt;seq &lt;&lt; ipcmni_seq_shift()) + idx

4. Later removal goes through ipc_rmid(), which uses:

       ipcid_to_idx(ipcp-&gt;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.
    </Details>
    <Details xml:lang="en:us" source="Red Hat">
A flaw was found in the Linux kernel. The `ipc_idr_alloc()` function, used in the checkpoint/restore path for SysV Inter-Process Communication (IPC) ID allocation, does not properly limit ID allocation to the valid range. This can result in the system attempting to dereference freed memory, leading to a use-after-free vulnerability. This issue could potentially cause system instability or information disclosure.
    </Details>
    <Statement xml:lang="en:us">
SysV IPC checkpoint restore next_id allocation can escape the valid IPC id range because ipc_idr_alloc used an open ended idr_alloc upper bound. A crafted local sequence can leave a shared memory object stored in an out of range IDR slot, while later removal truncates the encoded id and removes a different in range slot. This can leave a stale IDR pointer to freed shared memory state, and a later /proc/sysvipc/shm walk can dereference freed memory. Impact is local denial of service.
    </Statement>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:10">
        <ProductName>Red Hat Enterprise Linux 10</ProductName>
        <FixState>Affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:6">
        <ProductName>Red Hat Enterprise Linux 6</ProductName>
        <FixState>Out of support scope</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:7">
        <ProductName>Red Hat Enterprise Linux 7</ProductName>
        <FixState>Affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:7">
        <ProductName>Red Hat Enterprise Linux 7</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:8">
        <ProductName>Red Hat Enterprise Linux 8</ProductName>
        <FixState>Affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:8">
        <ProductName>Red Hat Enterprise Linux 8</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:9">
        <ProductName>Red Hat Enterprise Linux 9</ProductName>
        <FixState>Affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:9">
        <ProductName>Red Hat Enterprise Linux 9</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <References xml:lang="en:us">
https://www.cve.org/CVERecord?id=CVE-2026-52923
https://nvd.nist.gov/vuln/detail/CVE-2026-52923
https://lore.kernel.org/linux-cve-announce/2026062431-CVE-2026-52923-35fb@gregkh/T
    </References>
</Vulnerability>