CVE-2026-23158

What it actually does

Use-after-free in gpio-virtuser configfs release path allows mutex_unlock on already-freed device structure, enabling kernel memory corruption.

Why it matters to the business

Local users on affected Linux systems can trigger kernel crashes or escalate privileges, leading to system instability and potential compromise of hosts that expose gpio-virtuser via configfs.

How an attack unfolds

An attacker with local access creates and releases a gpio-virtuser device through configfs; the flawed release path destroys the mutex and frees the device while a guard still holds a reference, causing the subsequent unlock to operate on freed memory and corrupt kernel state.

How to fix it

Apply the upstream fix by updating the Linux kernel to commit 815a8e3bf72811d402b30bd4a53cde5e9df7a563 or later stable releases that contain the scoped_guard change; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the running kernel contains commit 815a8e3bf72811d402b30bd4a53cde5e9df7a563 via git log or kernel version string; attempt configfs device creation/release under controlled conditions and verify no slab UAF reports in dmesg.

Typical attack path

1. Obtain local shell on target Linux system
2. Interact with gpio-virtuser configfs group to allocate device
3. Trigger release path via removal or module unload
4. Exploit resulting use-after-free for memory corruption or code execution

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for slab use-after-free warnings or oops traces mentioning gpio_virtuser or mutex_unlock on freed memory; correlate with configfs activity timestamps.

What your security team should do

• Prioritize kernel update on all systems exposing gpio-virtuser
• Restrict local configfs access to trusted users until patched
• Monitor for kernel crashes referencing gpio_virtuser_device_config_group_release
• Test patched kernels in staging before broad deployment