From 75dc3e13fd1e903ba302acbe5cc3e1b3db895397 Mon Sep 17 00:00:00 2001 From: Sameeh Jubran Date: Mon, 27 Apr 2026 16:20:13 +0300 Subject: [PATCH] linuxkm/x86_vector_register_glue.c: fix struct pid refcount leak from find_get_pid() in wc_linuxkm_fpu_state_assoc_unlikely(). find_get_pid() returns a struct pid * with the refcount bumped via get_pid(); callers must release it with put_pid(). The probe here is purely a liveness check on the slot's previous owner, and the returned pointer was discarded -- leaking one struct pid reference every time the unlikely contested-slot path was hit with a still-live owner. Capture the pointer and put_pid() it on the live-owner branch; behavior on the orphaned-slot branch is unchanged. Signed-off-by: Sameeh Jubran --- linuxkm/x86_vector_register_glue.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/linuxkm/x86_vector_register_glue.c b/linuxkm/x86_vector_register_glue.c index 6879546337..90ae0efcc1 100644 --- a/linuxkm/x86_vector_register_glue.c +++ b/linuxkm/x86_vector_register_glue.c @@ -162,16 +162,22 @@ static struct wc_thread_fpu_count_ent *wc_linuxkm_fpu_state_assoc_unlikely(int c __atomic_store_n(&slot->pid, my_pid, __ATOMIC_RELEASE); return slot; } else { + struct pid *slot_pid_struct; + /* if the slot is already occupied, that can be benign-ish due to a * unwanted migration, or due to a process crashing in kernel mode. * it will require fixup either here, or by the thread that owns the * slot, which will happen when it releases its lock. */ - if (find_get_pid(slot_pid) == NULL) { + slot_pid_struct = find_get_pid(slot_pid); + if (slot_pid_struct == NULL) { if (__atomic_compare_exchange_n(&slot->pid, &slot_pid, my_pid, 0, __ATOMIC_SEQ_CST, __ATOMIC_ACQUIRE)) { pr_warn("WARNING: wc_linuxkm_fpu_state_assoc_unlikely fixed up orphaned slot on CPU %d owned by dead PID %d.\n", my_cpu, slot_pid); return slot; } + } else { + /* drop the refcount bumped by find_get_pid(). */ + put_pid(slot_pid_struct); } {