CVE-2026-52923

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipc: limit next_id allocation to the valid ID range<br /> <br /> The checkpoint/restore sysctl path can request the next SysV IPC id<br /> through ids-&gt;next_id. ipc_idr_alloc() currently forwards that request to<br /> idr_alloc() with an open-ended upper bound.<br /> <br /> If the valid tail of the SysV IPC id space is full, the allocation can<br /> spill beyond ipc_mni. The returned SysV IPC id still uses the normal<br /> index encoding, so later lookup and removal can target the wrong slot. <br /> This leaves the real IDR entry behind and breaks the IDR state for the<br /> object.<br /> <br /> The bug is in ipc_idr_alloc() in the checkpoint/restore path.<br /> <br /> 1. ids-&gt;next_id is passed to:<br /> <br /> idr_alloc(&amp;ids-&gt;ipcs_idr, new, ipcid_to_idx(next_id), 0, ...)<br /> <br /> 2. The zero upper bound makes the allocation effectively open-ended.<br /> Once the valid SysV IPC tail is occupied, idr_alloc() can spill past<br /> ipc_mni and allocate an entry beyond the valid IPC id range.<br /> <br /> 3. The new object id is still encoded with the narrower SysV IPC index<br /> width:<br /> <br /> new-&gt;id = (new-&gt;seq