CVE-2023-53728
posix-timers: Ensure timer ID search-loop limit is valid
Description
In the Linux kernel, the following vulnerability has been resolved: posix-timers: Ensure timer ID search-loop limit is valid posix_timer_add() tries to allocate a posix timer ID by starting from the cached ID which was stored by the last successful allocation. This is done in a loop searching the ID space for a free slot one by one. The loop has to terminate when the search wrapped around to the starting point. But that's racy vs. establishing the starting point. That is read out lockless, which leads to the following problem: CPU0 CPU1 posix_timer_add() start = sig->posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig->posix_timer_id < 0) start = sig->posix_timer_id; sig->posix_timer_id = 0; So CPU1 can observe a negative start value, i.e. -1, and the loop break never happens because the condition can never be true: if (sig->posix_timer_id == start) break; While this is unlikely to ever turn into an endless loop as the ID space is huge (INT_MAX), the racy read of the start value caught the attention of KCSAN and Dmitry unearthed that incorrectness. Rewrite it so that all id operations are under the hash lock.
INFO
Published Date :
Oct. 22, 2025, 2:15 p.m.
Last Modified :
Oct. 22, 2025, 9:12 p.m.
Remotely Exploit :
No
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Solution
- Acquire hash lock before accessing timer ID.
- Ensure ID operations are atomic under lock.
- Release hash lock after operations.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2023-53728.
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2023-53728 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2023-53728
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2023-53728 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2023-53728 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Oct. 22, 2025
Action Type Old Value New Value Added Description In the Linux kernel, the following vulnerability has been resolved: posix-timers: Ensure timer ID search-loop limit is valid posix_timer_add() tries to allocate a posix timer ID by starting from the cached ID which was stored by the last successful allocation. This is done in a loop searching the ID space for a free slot one by one. The loop has to terminate when the search wrapped around to the starting point. But that's racy vs. establishing the starting point. That is read out lockless, which leads to the following problem: CPU0 CPU1 posix_timer_add() start = sig->posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig->posix_timer_id < 0) start = sig->posix_timer_id; sig->posix_timer_id = 0; So CPU1 can observe a negative start value, i.e. -1, and the loop break never happens because the condition can never be true: if (sig->posix_timer_id == start) break; While this is unlikely to ever turn into an endless loop as the ID space is huge (INT_MAX), the racy read of the start value caught the attention of KCSAN and Dmitry unearthed that incorrectness. Rewrite it so that all id operations are under the hash lock. Added Reference https://git.kernel.org/stable/c/322377cc909defcca9451487484845e7e1d20d1b Added Reference https://git.kernel.org/stable/c/37175e25edf7cc0d5a2cd2c2a1cbe2dcbf4a1937 Added Reference https://git.kernel.org/stable/c/6a0ac84501b4fec73a1a823c55cf13584c43f418 Added Reference https://git.kernel.org/stable/c/8ad6679a5bb97cdb3e14942729292b4bfcc0e223 Added Reference https://git.kernel.org/stable/c/8ce8849dd1e78dadcee0ec9acbd259d239b7069f Added Reference https://git.kernel.org/stable/c/8dc52c200b889bc1cb34288fbf623d4ff381d2ae Added Reference https://git.kernel.org/stable/c/9ea26a8494a0a9337e7415eafd6f3ed940327dc5 Added Reference https://git.kernel.org/stable/c/ef535e0315afd098c4beb1da364847eca4b56a20