CVE-2025-38100: x86/iopl: Cure TIF_IO_BITMAP inconsistencies

In the Linux kernel, the following vulnerability has been resolved:

x86/iopl: Cure TIFIOBITMAP inconsistencies

iobitmapexit() is invoked from exitthread() when a task exists or when a fork fails. In the latter case the exitthread() cleans up resources which were allocated during fork().

iobitmapexit() invokes taskupdateiobitmap(), which in turn ends up in tssupdateiobitmap(). tssupdateiobitmap() operates on the current task. If current has TIFIOBITMAP set, but no bitmap installed, tssupdateiobitmap() crashes with a NULL pointer dereference.

There are two issues, which lead to that problem:

1) iobitmapexit() should not invoke taskupdateiobitmap() 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 TIFIOBITMAP 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 TIFIOBITMAP 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 tssupdateiobitmap().

Cure this by adding the missing cleanups and checks:

1) Prevent iobitmapexit() to invoke taskupdateiobitmap() if the to be cleaned up task is not the current task.

2) Clear TIFIOBITMAP in copythread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in iobitmapshare().

For paranoia sake, add a warning into tssupdateiobitmap() to catch the case, when that code is invoked with inconsistent state.