CVE-2023-53728
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-10-22

Last updated on: 2025-10-22

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-10-22
Last Modified
2025-10-22
Generated
2026-05-07
AI Q&A
2025-10-22
EPSS Evaluated
2026-05-05
NVD
CVE-2023-53728
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel's posix-timers involves a race condition in the timer ID allocation loop. The function posix_timer_add() tries to allocate a timer ID by starting from a cached ID stored from the last successful allocation. The search for a free ID slot is done in a loop that should terminate when the search wraps around to the starting point. However, the starting point is read without locking, which can lead to a negative start value being observed due to concurrent updates by multiple CPUs. This causes the loop termination condition to never be met, potentially resulting in an endless loop. The issue was fixed by ensuring all ID operations occur under a lock to prevent this race condition.


How can this vulnerability impact me? :

This vulnerability can cause the posix_timer_add() function to enter an endless loop due to a race condition in timer ID allocation. While the likelihood is low because the ID space is very large, if triggered, it could lead to a denial of service or system hang as the kernel function fails to complete properly.


What immediate steps should I take to mitigate this vulnerability?

Apply the patch or update the Linux kernel to a version where the posix-timers implementation ensures that all timer ID operations are performed under the hash lock, thereby fixing the race condition described. This prevents the potential endless loop caused by a racy read of the start value in posix_timer_add().


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart