Wind River Support Network

Description

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

CVEs

• CVE-2023-53728