CVE-2026-41948: Linux kernel s390 AP driver race condition
TL;DR - High-severity Linux kernel race condition in the s390 AP driver’s
cxe_guest_ioctl()path. - Affects kernels before 6.12.24, 6.13.x before 6.13.12, and 6.14.x before 6.14.1. - Patch if you expose AP queue devices to guests; no confirmed in-the-wild exploitation is currently known.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-41948 |
| CVSS v3.1 | 7.8 |
| Attack vector | Local |
| Auth required | Low privileges required |
| Patch status | Fixed in 6.12.24, 6.13.12, 6.14.1 |
Vulnerability at a glance
CVE-2026-41948 is a high-severity Linux kernel vulnerability in the s390 Cryptographic Adjunct Processor (AP) driver. According to the NVD description, the flaw exists in the cxe_guest_ioctl() function because the driver fails to hold the device lock while checking and changing queue states during queue reset handling. That race condition can lead to inconsistent state transitions and may trigger a kernel NULL pointer dereference or use-after-free.
From an operations perspective, this is not a broad internet-exposed remote code execution issue. It is a local flaw with AV:L, PR:L, and UI:N, which means an attacker needs local access and low privileges, but does not need user interaction. The issue matters most in s390 environments where guests can access AP queue devices. If that condition is not present, practical exposure is lower; if it is present, defenders should treat the issue as a real stability and isolation concern until patched.
What is this vulnerability?
The root cause is a race condition in queue reset handling in cxe_guest_ioctl(). The available description is specific: queue state checks and state changes occur without holding the required device lock. In kernel-space code, that is a classic synchronization failure. When multiple operations hit the same queue path concurrently, the software can make decisions based on stale or inconsistent state, creating dangerous execution paths.
The consequences described by the NVD are serious even without confirmed privilege escalation language. The bug can produce a kernel NULL pointer dereference, a use-after-free, or other undefined behavior during queue reset operations. In practice, undefined behavior in a kernel driver is enough to justify rapid patching, especially in multi-tenant or guest-exposed environments. Even if your main concern is availability, a guest-triggerable kernel fault on specialized crypto queue infrastructure is operationally significant.
Technical Notes
The vulnerable area is identified as the Linux kernel crypto/s390/pkey path, specifically cxe_guest_ioctl() queue reset handling. The Red Hat Bugzilla title aligns with the NVD summary:
kernel: crypto: s390/pkey - Fix race in cxe_guest_ioctl queue reset handling
NVD also lists stable backport references associated with the fix across branches:
https://git.kernel.org/stable/c/4b5e5c3f7649187f78d5f0ff4ba002fdcc29f9d4
https://git.kernel.org/stable/c/5e1f4f2e55cc04510d01e3a5efdbf6dd767fdd2e
https://git.kernel.org/stable/c/f41ce7b4f0227b4d96fc0b7cc7dbcc5f9cbca6f6
Who is affected?
The affected product is the Linux kernel, specifically the s390 Cryptographic Adjunct Processor (AP) driver. This is not a generic all-platform Linux bug in the same way as a networking stack flaw. The impact is concentrated in s390 deployments where the AP driver is relevant and where guests have access to AP queue devices. That environment note matters because the NVD explicitly calls out guest access to AP queue devices as the risk context.
The affected version ranges are clearly stated and should be quoted exactly for asset validation and change control. Affected versions are Linux kernel before 6.12.24, from 6.13 before 6.13.12, and from 6.14 before 6.14.1. The first fixed versions are 6.12.24, 6.13.12, and 6.14.1. If your fleet uses vendor kernels with backports, you should not rely only on uname -r; verify the vendor advisory and package changelog because vendors often fix flaws without matching the upstream version string exactly.
For defenders, the practical question is not only “Do we run Linux?” but “Do we run Linux on s390, and do guests reach AP queue devices?” If the answer is no, exposure may be theoretical in your environment. If the answer is yes or unknown, assume exposure until proven otherwise. Unknowns around guest access paths should be treated conservatively because local kernel races often surface first as reliability issues before being fully characterized for broader impact.
Technical Notes
Check kernel version and architecture first:
uname -r
uname -m
On potentially affected systems, review whether relevant s390 AP driver modules or device paths are present:
lsmod | egrep 'ap|pkey'
find /sys -maxdepth 3 \( -iname '*ap*' -o -iname '*pkey*' \) 2>/dev/null | head -100
If you use packaged kernels, inspect changelogs rather than assuming version strings tell the whole story:
# RHEL-like
rpm -q --changelog kernel | egrep -i 'CVE-2026-41948|cxe_guest_ioctl|s390|pkey' -n
# Debian/Ubuntu-like
apt changelog linux-image-$(uname -r) 2>/dev/null | egrep -i 'CVE-2026-41948|cxe_guest_ioctl|s390|pkey'
Exploitation status and risk
At the time of writing, exploitation in the wild is not confirmed. The CVE is not listed in CISA KEV, which means there is currently no CISA-confirmed known exploitation record for this issue. That does not mean exploitation is impossible; it means defenders should avoid overstating what is known. In environments where local attackers or untrusted guests exist, kernel race conditions still deserve prompt remediation because they can be used for denial of service and potentially more severe outcomes depending on runtime conditions.
As for exploit code, no public proof-of-concept (PoC) was identified in the provided references. The available material points to vulnerability tracking and stable kernel fixes, but not to a published exploit. In the absence of a known PoC, defenders should assume two things: first, that reproducing the race may still be feasible for a determined local attacker; second, that public exploit availability can change quickly once patch diffs are examined. Patch-first remains the right approach.
A key nuance here is the CVSS vector: AV:L/AC:L/PR:L/UI:N. This is not a no-access bug; the attacker must already have local access and low privileges. For many enterprises, that places the issue behind existing access controls. For shared s390 platforms or environments with guest workloads that are not fully trusted, the risk is materially higher because low-privilege local flaws can become tenant separation problems or service availability incidents.
CVSS breakdown and what it means operationally
The CVSS v3.1 base score is 7.8 (High) with vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. The important operational takeaway is that exploitation does not require user interaction and is considered low complexity once the attacker has local low-privilege access. The high confidentiality, integrity, and availability impacts in the vector reflect the severity kernel flaws can carry even when they are not remotely reachable.
That said, defenders should read this score in context. A local kernel bug on s390 AP queue handling is less universally urgent than a remotely exploitable edge-device flaw, but more urgent than a low-impact local issue because it affects kernel stability and potentially trust boundaries in guest-access scenarios. Prioritization should therefore be highest for s390 virtualization environments, shared infrastructure, and systems where untrusted or semi-trusted local users can interact with the affected functionality.
How to detect exposure or active abuse
Detection for this CVE is less about spotting a remote network exploit and more about identifying susceptible systems and watching for crash symptoms or queue reset anomalies in relevant environments. Start with asset and configuration discovery: identify s390 systems, determine whether AP queue devices are exposed to guests, and inventory kernel versions against the affected ranges. That will usually provide more value than trying to hunt for a highly specific exploit signature that may not yet exist publicly.
For possible active abuse or failed exploitation, focus on kernel logs and crash indicators around AP queue handling, NULL dereferences, use-after-free symptoms, and queue reset activity. Because the public description does not provide a vendor-authored detection signature, defenders should avoid claiming a precise IOC set. Instead, monitor for correlated evidence: unusual guest-triggered queue resets, kernel oops/panic messages, KASAN reports if enabled, and service instability on systems using the s390 AP driver.
Technical Notes
Example log patterns worth monitoring in journald, /var/log/messages, or SIEM pipelines:
BUG: kernel NULL pointer dereference
general protection fault
KASAN: use-after-free
Unable to handle kernel pointer dereference
Oops:
crypto: s390
pkey
cxe_guest_ioctl
queue reset
Example journalctl hunting command:
journalctl -k --since "7 days ago" | egrep -i 'NULL pointer dereference|use-after-free|Oops:|general protection fault|KASAN|cxe_guest_ioctl|crypto: s390|pkey|queue reset'
Example Splunk query:
index=os_logs sourcetype=linux:kern
("cxe_guest_ioctl" OR "crypto: s390" OR "pkey" OR "queue reset" OR "NULL pointer dereference" OR "use-after-free" OR "general protection fault" OR "KASAN")
| stats count by host, _time, message
Example Sigma-style keyword logic defenders can adapt:
title: Possible CVE-2026-41948 Kernel Symptom Detection
logsource:
product: linux
service: kernel
detection:
selection:
Message|contains:
- 'cxe_guest_ioctl'
- 'crypto: s390'
- 'pkey'
- 'queue reset'
- 'NULL pointer dereference'
- 'use-after-free'
- 'KASAN'
condition: selection
level: medium
Mitigation and patching
The primary mitigation is to move to a fixed kernel version. The first known fixed versions are 6.12.24, 6.13.12, and 6.14.1. If you run an enterprise distribution with backported fixes, apply the vendor kernel package that references CVE-2026-41948 or the associated s390/pkey queue reset fix. Do not delay patching simply because there is no confirmed KEV entry or public PoC; kernel race conditions in guest-reachable paths should be handled on a risk basis, not a publicity basis.
If immediate patching is not possible, reduce exposure by restricting guest access to AP queue devices where operationally feasible. The NVD description specifically frames risk in environments where a guest has access to AP queue devices, so temporarily removing or limiting that access is the most defensible workaround based on available facts. If you cannot determine whether guests have AP queue access, assume they might and escalate validation with your virtualization or platform team.
Because this is a kernel fix, plan for a reboot after package installation unless your vendor explicitly provides and supports an alternative live patch mechanism for this issue. Also verify post-change behavior in any workloads that depend on s390 crypto acceleration, since security fixes in specialized device paths can intersect with performance-sensitive operations.
Technical Notes
Examples of upgrade workflows defenders can adapt:
# RHEL / Rocky / Alma / CentOS Stream
sudo dnf update kernel kernel-core kernel-modules -y
sudo reboot
# Debian / Ubuntu
sudo apt update
sudo apt install --only-upgrade linux-image-generic linux-headers-generic -y
sudo reboot
# SUSE
sudo zypper patch
sudo reboot
Verify the running kernel after reboot:
uname -r
If you need a temporary workaround, reduce or remove guest exposure to AP queue devices. Exact steps depend on your virtualization and s390 configuration, so no single universal command can be stated safely from the available data. What defenders should do immediately is identify attached AP-related devices and coordinate their removal or restriction through the supported host or hypervisor tooling for that environment:
ls /sys/bus/ap/devices 2>/dev/null
In the absence of a vendor-published workaround sequence in the available references, the safest assumption is: patching is the authoritative fix; restricting guest AP queue access is the interim control.
References
Primary references for this CVE are the NVD description, Red Hat tracking, and upstream stable kernel fix links. These are the sources defenders should use to validate impact and patch status rather than relying on secondary summaries.
- NVD CVE record for CVE-2026-41948
- Red Hat CVE page: https://access.redhat.com/security/cve/CVE-2026-41948
- Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2378887
- Stable kernel fix references:
- https://git.kernel.org/stable/c/4b5e5c3f7649187f78d5f0ff4ba002fdcc29f9d4
- https://git.kernel.org/stable/c/5e1f4f2e55cc04510d01e3a5efdbf6dd767fdd2e
- https://git.kernel.org/stable/c/f41ce7b4f0227b4d96fc0b7cc7dbcc5f9cbca6f6
For more information on similar vulnerabilities, refer to our articles on Insecure Direct Object Reference and Third Party Risk Management Basics.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.