| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <2025102816-CVE-2025-40061-ea17@gregkh> Date: Tue, 28 Oct 2025 12:48:38 +0100 From: Greg Kroah-Hartman <gregkh@...uxfoundation.org> To: linux-cve-announce@...r.kernel.org Cc: Greg Kroah-Hartman <gregkh@...nel.org> Subject: CVE-2025-40061: RDMA/rxe: Fix race in do_task() when draining From: Greg Kroah-Hartman <gregkh@...nel.org> Description =========== In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix race in do_task() when draining When do_task() exhausts its iteration budget (!ret), it sets the state to TASK_STATE_IDLE to reschedule, without a secondary check on the current task->state. This can overwrite the TASK_STATE_DRAINING state set by a concurrent call to rxe_cleanup_task() or rxe_disable_task(). While state changes are protected by a spinlock, both rxe_cleanup_task() and rxe_disable_task() release the lock while waiting for the task to finish draining in the while(!is_done(task)) loop. The race occurs if do_task() hits its iteration limit and acquires the lock in this window. The cleanup logic may then proceed while the task incorrectly reschedules itself, leading to a potential use-after-free. This bug was introduced during the migration from tasklets to workqueues, where the special handling for the draining case was lost. Fix this by restoring the original pre-migration behavior. If the state is TASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to force a new loop iteration. This allows the task to finish its work, so that a subsequent iteration can reach the switch statement and correctly transition the state to TASK_STATE_DRAINED, stopping the task as intended. The Linux kernel CVE team has assigned CVE-2025-40061 to this issue. Affected and fixed versions =========================== Issue introduced in 6.5 with commit 9b4b7c1f9f54120940e243251e2b1407767b3381 and fixed in 6.6.112 with commit 85288bcf7ffe11e7b036edf91937bc62fd384076 Issue introduced in 6.5 with commit 9b4b7c1f9f54120940e243251e2b1407767b3381 and fixed in 6.12.53 with commit 52edccfb555142678c836c285bf5b4ec760bd043 Issue introduced in 6.5 with commit 9b4b7c1f9f54120940e243251e2b1407767b3381 and fixed in 6.17.3 with commit 660b6959c4170637f5db2279d1f71af33a49e49b Issue introduced in 6.5 with commit 9b4b7c1f9f54120940e243251e2b1407767b3381 and fixed in 6.18-rc1 with commit 8ca7eada62fcfabf6ec1dc7468941e791c1d8729 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-2025-40061 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: drivers/infiniband/sw/rxe/rxe_task.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/85288bcf7ffe11e7b036edf91937bc62fd384076 https://git.kernel.org/stable/c/52edccfb555142678c836c285bf5b4ec760bd043 https://git.kernel.org/stable/c/660b6959c4170637f5db2279d1f71af33a49e49b https://git.kernel.org/stable/c/8ca7eada62fcfabf6ec1dc7468941e791c1d8729
Powered by blists - more mailing lists