CVE-2025-38100

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/iopl: Cure TIF_IO_BITMAP inconsistencies<br /> <br /> io_bitmap_exit() is invoked from exit_thread() when a task exists or<br /> when a fork fails. In the latter case the exit_thread() cleans up<br /> resources which were allocated during fork().<br /> <br /> io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up<br /> in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the<br /> current task. If current has TIF_IO_BITMAP set, but no bitmap installed,<br /> tss_update_io_bitmap() crashes with a NULL pointer dereference.<br /> <br /> There are two issues, which lead to that problem:<br /> <br /> 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when<br /> the task, which is cleaned up, is not the current task. That&amp;#39;s a<br /> clear indicator for a cleanup after a failed fork().<br /> <br /> 2) A task should not have TIF_IO_BITMAP set and neither a bitmap<br /> installed nor IOPL emulation level 3 activated.<br /> <br /> This happens when a kernel thread is created in the context of<br /> a user space thread, which has TIF_IO_BITMAP set as the thread<br /> flags are copied and the IO bitmap pointer is cleared.<br /> <br /> Other than in the failed fork() case this has no impact because<br /> kernel threads including IO workers never return to user space and<br /> therefore never invoke tss_update_io_bitmap().<br /> <br /> Cure this by adding the missing cleanups and checks:<br /> <br /> 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if<br /> the to be cleaned up task is not the current task.<br /> <br /> 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user<br /> space forks it is set later, when the IO bitmap is inherited in<br /> io_bitmap_share().<br /> <br /> For paranoia sake, add a warning into tss_update_io_bitmap() to catch<br /> the case, when that code is invoked with inconsistent state.