CVE-2023-53728

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> posix-timers: Ensure timer ID search-loop limit is valid<br /> <br /> posix_timer_add() tries to allocate a posix timer ID by starting from the<br /> cached ID which was stored by the last successful allocation.<br /> <br /> This is done in a loop searching the ID space for a free slot one by<br /> one. The loop has to terminate when the search wrapped around to the<br /> starting point.<br /> <br /> But that&amp;#39;s racy vs. establishing the starting point. That is read out<br /> lockless, which leads to the following problem:<br /> <br /> CPU0 CPU1<br /> posix_timer_add()<br /> start = sig-&gt;posix_timer_id;<br /> lock(hash_lock);<br /> ... posix_timer_add()<br /> if (++sig-&gt;posix_timer_id posix_timer_id;<br /> sig-&gt;posix_timer_id = 0;<br /> <br /> So CPU1 can observe a negative start value, i.e. -1, and the loop break<br /> never happens because the condition can never be true:<br /> <br /> if (sig-&gt;posix_timer_id == start)<br /> break;<br /> <br /> While this is unlikely to ever turn into an endless loop as the ID space is<br /> huge (INT_MAX), the racy read of the start value caught the attention of<br /> KCSAN and Dmitry unearthed that incorrectness.<br /> <br /> Rewrite it so that all id operations are under the hash lock.