[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2025070319-CVE-2025-38100-5040@gregkh>
Date: Thu, 3 Jul 2025 10:35:18 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-38100: x86/iopl: Cure TIF_IO_BITMAP inconsistencies
From: Greg Kroah-Hartman <gregkh@...nel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
x86/iopl: Cure TIF_IO_BITMAP inconsistencies
io_bitmap_exit() is invoked from exit_thread() when a task exists or
when a fork fails. In the latter case the exit_thread() cleans up
resources which were allocated during fork().
io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up
in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the
current task. If current has TIF_IO_BITMAP set, but no bitmap installed,
tss_update_io_bitmap() crashes with a NULL pointer dereference.
There are two issues, which lead to that problem:
1) io_bitmap_exit() should not invoke task_update_io_bitmap() when
the task, which is cleaned up, is not the current task. That's a
clear indicator for a cleanup after a failed fork().
2) A task should not have TIF_IO_BITMAP set and neither a bitmap
installed nor IOPL emulation level 3 activated.
This happens when a kernel thread is created in the context of
a user space thread, which has TIF_IO_BITMAP set as the thread
flags are copied and the IO bitmap pointer is cleared.
Other than in the failed fork() case this has no impact because
kernel threads including IO workers never return to user space and
therefore never invoke tss_update_io_bitmap().
Cure this by adding the missing cleanups and checks:
1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if
the to be cleaned up task is not the current task.
2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user
space forks it is set later, when the IO bitmap is inherited in
io_bitmap_share().
For paranoia sake, add a warning into tss_update_io_bitmap() to catch
the case, when that code is invoked with inconsistent state.
The Linux kernel CVE team has assigned CVE-2025-38100 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.5 with commit ea5f1cd7ab494f65f50f338299eabb40ad6a1767 and fixed in 5.10.239 with commit d64b7b05a827f98d068f412969eef65489b0cf03
Issue introduced in 5.5 with commit ea5f1cd7ab494f65f50f338299eabb40ad6a1767 and fixed in 5.15.186 with commit 2dace5e016c991424a3dc6e83b1ae5dca8992d08
Issue introduced in 5.5 with commit ea5f1cd7ab494f65f50f338299eabb40ad6a1767 and fixed in 6.1.142 with commit aa5ce1485562f20235b4c759eee5ab0c41d2c220
Issue introduced in 5.5 with commit ea5f1cd7ab494f65f50f338299eabb40ad6a1767 and fixed in 6.6.94 with commit 2cfcbe1554c119402e7382de974c26b0549899fe
Issue introduced in 5.5 with commit ea5f1cd7ab494f65f50f338299eabb40ad6a1767 and fixed in 6.12.34 with commit b3b3b6366dc8eb5b22edba9adc4bff3cdacfd64c
Issue introduced in 5.5 with commit ea5f1cd7ab494f65f50f338299eabb40ad6a1767 and fixed in 6.15.3 with commit 73cfcc8445585b8af7e18be3c9246b851fdf336c
Issue introduced in 5.5 with commit ea5f1cd7ab494f65f50f338299eabb40ad6a1767 and fixed in 6.16-rc1 with commit 8b68e978718f14fdcb080c2a7791c52a0d09bc6d
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-38100
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:
arch/x86/kernel/ioport.c
arch/x86/kernel/process.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/d64b7b05a827f98d068f412969eef65489b0cf03
https://git.kernel.org/stable/c/2dace5e016c991424a3dc6e83b1ae5dca8992d08
https://git.kernel.org/stable/c/aa5ce1485562f20235b4c759eee5ab0c41d2c220
https://git.kernel.org/stable/c/2cfcbe1554c119402e7382de974c26b0549899fe
https://git.kernel.org/stable/c/b3b3b6366dc8eb5b22edba9adc4bff3cdacfd64c
https://git.kernel.org/stable/c/73cfcc8445585b8af7e18be3c9246b851fdf336c
https://git.kernel.org/stable/c/8b68e978718f14fdcb080c2a7791c52a0d09bc6d
Powered by blists - more mailing lists