CVE-2026-80916: kcov: fix data corruption and race conditions on PREEMPT_RT

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

kcov: fix data corruption and race conditions on PREEMPTRT

syzbot is reporting KCOV state corruption on PREEMPTRT kernels, for the temporary storage used for saving/restoring remote KCOV state is currently allocated as the per-CPU area.

On PREEMPTRT kernels, softirq handlers run as preemptible task threads (e.g., ksoftirqd). If a softirq context preempts a task running a remote KCOV session, it safely saves the task's state into the per-CPU area. However, if that softirq thread is subsequently preempted by a higher- priority softirq thread on the same CPU, the second softirq will overwrite the same per-CPU area, permanently destroying the original task's KCOV state.

Fix this data corruption by moving the temporary storage from the per-CPU area to the per-thread area. Since each softirq thread now owns its own task context, nested softirq preemption no longer causes data overwrites.

Note that while the temporary storage is now on a per-thread basis, the per-CPU kcovpercpudata.lock must be retained, for we need to ensure that kcovremotestart() and kcovremotestop() operate atomically without racing against asynchronous interrupts that manipulate the current task's KCOV state.

It is likely that GFPKERNEL allocation by vmallocnode() in kcovinit() has already called panic() before returning NULL, for there will be no OOM-killable userspace processes when init function of built-in module runs. But this patch also fixes crashing the kernel when vmallocnode() in kcovinit() returned NULL, for kcovinit() left per-CPU irqarea == NULL but kcovremotestart() depends on per-CPU irqarea != NULL, resulting in

(1) doing vmalloc() in kcovremotestart() despite !intask() context

(2) out-of-array-bounds access if (1) succeeded but kcov->remotesize < CONFIGKCOVIRQAREASIZE

(3) always leak memory allocated by (1), eventually killing all OOM-killable userspace processes

problems.