CVE-2026-43109

What it actually does

This is a local Linux kernel denial-of-service flaw in the x86 user shadow stack signal-return path. The vulnerable code path, shstk_pop_sigframe(), failed to check the return value from mmap_read_lock_killable(). If that lock acquisition is interrupted or fails, the kernel can continue as though the memory map lock was successfully held, leading to an invalid kernel state that may cause a crash, kernel oops, or system instability. The impact is availability only: the published CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, no confidentiality impact, no integrity impact, and high availability impact.

Why it matters to the business

An attacker who already has the ability to run code locally on an affected Linux system may be able to crash or destabilize that host. This can interrupt workloads, cause service downtime, force reboots, and affect multi-user systems, shared compute, CI/CD runners, developer workstations, or servers that allow local shell access or run untrusted workloads. The current risk signals are relatively low: EPSS is very low and flat over 30 days, there is no known CISA KEV listing, no known ransomware use, and no reported public exploit maturity in the provided data. However, because the Linux kernel is widely deployed and outages can be operationally significant, affected systems should still receive the vendor kernel fix through normal patch cycles, with higher priority for systems exposed to untrusted local users or containers.

How an attack unfolds

An attacker first needs local code execution with low privileges on an affected x86 Linux system where user shadow stack functionality is present. They then run a program that exercises signal handling and shadow-stack state while creating conditions where mmap_read_lock_killable() can fail or be interrupted. Because the vulnerable kernel path does not properly handle that failure, the kernel may proceed without the expected memory-map lock, corrupting assumptions inside the signal-frame shadow-stack handling path. The likely result is a kernel oops, panic, hang, or other instability that denies service to users and workloads on the host. The flaw does not provide a direct path to data theft or privilege escalation based on the supplied description and scoring.

How to fix it

Apply the Linux kernel update from the operating system or distribution vendor that includes the upstream fix for the x86 shadow stack mmap lock error-handling bug. No exact fixed package versions were provided in the input, so use vendor advisories and package metadata for the authoritative fixed kernel versions for each distribution. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted code execution, isolating multi-tenant workloads, and applying standard hardening controls for local users and containers. If supported and operationally acceptable, disabling user shadow stack support, for example through a vendor-supported kernel configuration or boot option such as a user-shadow-stack disablement option, may reduce exposure, but this can remove a defense-in-depth memory-safety feature and should be tested before production use. Reboot systems after installing kernel updates so the fixed kernel is actually running.

How to confirm the fix worked

Confirm remediation by verifying that systems are booted into a vendor kernel version that includes the fix, not merely that an updated package is installed. Use commands such as uname -a and the distribution package manager to compare the running kernel against the vendor advisory for this vulnerability. Review boot history to ensure a reboot occurred after the kernel update. On representative x86 systems, validate that normal signal-heavy workloads and applications using control-flow enforcement/shadow-stack features run without kernel oops or panic messages. Check kernel logs with journalctl -k, dmesg, or centralized log collection for stack traces referencing shstk_pop_sigframe or mmap_read_lock_killable before and after patching. For exposure assessment, inventory Linux x86 hosts, especially those allowing local users, build jobs, remote shells, container workloads, or other untrusted local execution.

Typical attack path

1. Obtain the ability to execute code as an unprivileged local user on an affected x86 Linux system.
2. Confirm the host is running a vulnerable kernel build with user shadow stack support present or enabled.
3. Run a local program that repeatedly exercises signal delivery/return behavior involving shadow-stack state.
4. Trigger or race conditions where mmap_read_lock_killable() returns an error while shstk_pop_sigframe() is executing.
5. Cause the kernel to continue through the vulnerable path without properly handling the failed lock acquisition.
6. Induce a kernel crash, oops, hang, or reboot, resulting in denial of service for the affected system.

How to detect it

Detection should focus on signs of attempted or successful local denial of service rather than remote network indicators. Review kernel logs from journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, and centralized Linux telemetry for oops, panic, BUG, warning, hung task, general protection fault, or page fault events that include shadow-stack or mmap-lock related stack frames. Look specifically for stack traces containing shstk_pop_sigframe, mmap_read_lock_killable, signal handling, or x86 shadow stack functions. Correlate crash timestamps with auditd, process accounting, EDR, shell history where available, CI/CD job logs, container runtime logs, and sudo/session logs to identify the local user or workload executing immediately before the crash. Because this is a local DoS issue, useful artifacts may include repeated short-lived processes, signal-heavy test binaries, fuzzers, or job-runner tasks preceding kernel instability. There are no known public exploit indicators, threat actor associations, KEV exploitation, or ransomware usage in the provided data, so detections should be behavior- and crash-artifact-based rather than signature-based.

• shstk_pop_sigframe
• mmap_read_lock_killable
• x86: shadow stacks
• shadow stacks
• kernel BUG
• kernel panic
• Oops:
• general protection fault
• BUG: unable to handle page fault
• RIP: shstk_pop_sigframe
• Call Trace:
• journalctl -k
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Inventory affected Linux x86 systems and identify hosts that allow untrusted local code execution, shared shell access, CI/CD jobs, container workloads, or multi-user access.
• Prioritize kernel updates for shared, multi-tenant, internet-facing service platforms with local execution paths, and high-availability production systems where a local crash would cause material downtime.
• Apply the vendor-supplied kernel update and reboot into the fixed kernel; do not rely on package installation alone.
• Monitor distribution advisories for exact fixed kernel package versions because no fixed versions were provided in the input.
• If patching must be delayed, restrict local user access, tighten container and job-runner isolation, and consider disabling user shadow stack support only where vendor-supported and after risk review.
• Add temporary detections for kernel oops, panic, or stack traces mentioning shstk_pop_sigframe or mmap_read_lock_killable.
• Treat evidence of repeated local crashes, especially from the same user, job runner, or workload, as suspicious even though no public exploit maturity or KEV exploitation is currently indicated.
• Maintain normal vulnerability management priority rather than emergency response for most environments, given the low and flat EPSS, lack of KEV status, and no known ransomware use in the provided data.