[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2025102216-CVE-2023-53728-b851@gregkh>
Date: Wed, 22 Oct 2025 15:25:07 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2023-53728: posix-timers: Ensure timer ID search-loop limit is valid
From: Greg Kroah-Hartman <gregkh@...nel.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.
The Linux kernel CVE team has assigned CVE-2023-53728 to this issue.
Affected and fixed versions
===========================
Fixed in 4.14.322 with commit 8dc52c200b889bc1cb34288fbf623d4ff381d2ae
Fixed in 4.19.291 with commit 9ea26a8494a0a9337e7415eafd6f3ed940327dc5
Fixed in 5.4.251 with commit 8ad6679a5bb97cdb3e14942729292b4bfcc0e223
Fixed in 5.10.188 with commit 322377cc909defcca9451487484845e7e1d20d1b
Fixed in 5.15.150 with commit ef535e0315afd098c4beb1da364847eca4b56a20
Fixed in 6.1.107 with commit 6a0ac84501b4fec73a1a823c55cf13584c43f418
Fixed in 6.4.7 with commit 37175e25edf7cc0d5a2cd2c2a1cbe2dcbf4a1937
Fixed in 6.5 with commit 8ce8849dd1e78dadcee0ec9acbd259d239b7069f
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2023-53728
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
include/linux/sched/signal.h
kernel/time/posix-timers.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/8dc52c200b889bc1cb34288fbf623d4ff381d2ae
https://git.kernel.org/stable/c/9ea26a8494a0a9337e7415eafd6f3ed940327dc5
https://git.kernel.org/stable/c/8ad6679a5bb97cdb3e14942729292b4bfcc0e223
https://git.kernel.org/stable/c/322377cc909defcca9451487484845e7e1d20d1b
https://git.kernel.org/stable/c/ef535e0315afd098c4beb1da364847eca4b56a20
https://git.kernel.org/stable/c/6a0ac84501b4fec73a1a823c55cf13584c43f418
https://git.kernel.org/stable/c/37175e25edf7cc0d5a2cd2c2a1cbe2dcbf4a1937
https://git.kernel.org/stable/c/8ce8849dd1e78dadcee0ec9acbd259d239b7069f
Powered by blists - more mailing lists