CVE-2026-43115

What it actually does

This is a Linux kernel concurrency/lifetime bug in Tiny SRCU. The vulnerable code path can invoke workqueue scheduling while scheduler-related locks are already held, creating an unsafe lock-ordering condition involving the scheduler pi_lock and the workqueue pool lock. The fix changes Tiny SRCU grace-period startup to use irq_work as an intermediate mechanism and adds synchronization during SRCU cleanup to prevent queued irq_work from firing after the SRCU structure is being destroyed. The practical impact is local availability risk: a user or local process able to trigger the affected kernel path may cause lockdep warnings, kernel hangs, deadlocks, or a crash. The vulnerability is not described as enabling confidentiality loss, data modification, or remote code execution.

Why it matters to the business

Systems running affected Linux kernels may be exposed to local denial-of-service conditions where an authenticated local user, compromised workload, containerized process with sufficient kernel interaction, or local application can destabilize the host. For organizations operating shared Linux infrastructure, build systems, developer workstations, appliances, embedded Linux devices, or multi-tenant compute platforms, the main operational risk is host outage, workload interruption, and unplanned reboot or recovery. Current public exploitation indicators are low: EPSS is 0.001 with no 30-day increase, it is not listed in CISA KEV, and no mature public exploit is indicated, but kernel availability bugs should still be addressed through normal kernel maintenance because they can be disruptive when triggered intentionally or by unstable workloads.

How an attack unfolds

An attacker first needs local code execution or the ability to run a workload on a vulnerable Linux system. They then exercise kernel functionality that reaches call_srcu() in a context where scheduler locks are held and Tiny SRCU attempts to start a grace period. In the vulnerable implementation, srcu_gp_start_if_needed() directly calls schedule_work(), which can acquire the workqueue pool lock while the scheduler pi_lock is already held. A competing workqueue path can hold the pool lock and attempt to wake a worker, which reaches scheduler wake-up logic and needs pi_lock, producing an inverted lock dependency. Separately, if SRCU cleanup races with queued irq_work, the queued work can run after the SRCU structure is being cleaned up, creating a use-after-free hazard. A successful attack would not normally yield privileges; the expected attacker objective is to hang, panic, or crash the kernel and deny service to the host and workloads running on it.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for Tiny SRCU using irq_work to start grace periods and irq_work_sync() during SRCU cleanup. Because no exact fixed package versions were provided, use the fixed kernel versions published by the applicable Linux distribution, appliance vendor, cloud image provider, or embedded platform maintainer. Prioritize systems that allow untrusted or semi-trusted local code execution, including multi-user servers, container hosts, CI/CD runners, developer workstations, shared research systems, and edge/embedded devices. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, applying least privilege and container isolation, disabling unnecessary local accounts, and ensuring watchdog and reboot procedures are in place for critical systems. Reboot into the patched kernel after installation; merely installing kernel packages is not sufficient if the running kernel is still vulnerable.

How to confirm the fix worked

Confirm remediation by verifying that each system is booted into a vendor kernel version containing the fix, not only that a patched package is installed. Use uname -r and distribution package metadata to compare the running kernel against the vendor advisory. Where source validation is possible, confirm the Tiny SRCU implementation no longer directly starts the grace-period work through schedule_work() in the vulnerable path and that SRCU cleanup synchronizes pending irq_work. Review kernel logs after upgrade for absence of recurring lockdep, workqueue, SRCU, RCU, soft lockup, hard lockup, or kernel panic messages associated with call_srcu(), srcu_gp_start_if_needed(), schedule_work(), create_worker(), wake_up_process(), try_to_wake_up(), or cleanup_srcu_struct(). For fleet validation, inventory kernel versions across Linux assets and flag hosts running affected or unknown kernels, especially long-lived systems that have installed updates but not rebooted.

Typical attack path

1. Obtain local execution on a Linux system running an affected kernel configuration using Tiny SRCU.
2. Run code or a workload that repeatedly triggers SRCU callback/grace-period activity through kernel interfaces that reach call_srcu().
3. Increase timing pressure and concurrency to make the lock-ordering race or SRCU cleanup race more likely.
4. Cause a kernel lockup, deadlock, warning escalation, panic, or crash depending on kernel configuration and panic-on-warning/lockup settings.
5. Use the resulting host instability to interrupt services, terminate workloads, or force administrative recovery.

How to detect it

To determine whether this issue may already have been triggered, review local kernel telemetry rather than application logs. Primary sources are dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, persistent journald storage, crash dump directories, kernel panic records, hypervisor reset events, and EDR telemetry that captures kernel panic or system reboot reasons. Search for lockdep dependency warnings involving call_srcu(), srcu_gp_start_if_needed(), schedule_work(), workqueue pool locks, wake_up_process(), try_to_wake_up(), create_worker(), cleanup_srcu_struct(), SRCU, RCU, irq_work, soft lockups, hard lockups, and use-after-free reports. Correlate suspicious kernel warnings or crashes with local user sessions, newly started containers, CI jobs, fuzzing workloads, untrusted scripts, or repeated workload launches immediately before the event. Exploitation may leave no durable file artifact; the strongest evidence is a sequence of kernel warnings or lockups followed by a panic, hang, watchdog reset, or unplanned reboot on an affected kernel. If kernel crash dumps are available, inspect stack traces for the affected functions and workqueue/SRCU interaction.

• lockdep splat
• possible circular locking dependency detected
• call_srcu
• srcu_gp_start_if_needed
• schedule_work
• workqueue_init
• create_worker
• wake_up_process
• try_to_wake_up
• cleanup_srcu_struct
• irq_work_sync
• Tiny SRCU
• SRCU-T
• rcutorture SRCU-T
• pool->lock
• pi_lock
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• general protection fault
• kernel panic
• soft lockup
• hard lockup
• RCU stall
• rcu: INFO: rcu_preempt detected stalls
• INFO: task blocked for more than

What your security team should do

• Inventory Linux systems and identify hosts running kernels that predate the vendor fix for this Tiny SRCU issue.
• Prioritize patching and rebooting shared, multi-user, container-hosting, CI/CD, and internet-facing service infrastructure where local code execution by less-trusted users or workloads is plausible.
• Monitor kernel logs for lockdep splats, RCU/SRCU warnings, workqueue lock-order warnings, soft lockups, hard lockups, and unexpected kernel panics.
• If patching is delayed, restrict local login access and reduce the ability of untrusted users or workloads to execute arbitrary code on affected hosts.
• Ensure operational runbooks cover kernel lockup recovery, including console access, watchdog behavior, crash dump collection, and safe reboot procedures.
• Track distribution and appliance vendor advisories for exact fixed kernel package versions and confirm systems have rebooted into the patched kernel.
• Because EPSS is low, KEV status is false, and exploit maturity is currently none, treat this as a routine-to-prioritized kernel stability fix rather than an emergency internet-wide remote exploitation event.