CVE-2026-43311

What it actually does

This is a Linux kernel availability flaw in the NVIDIA Tegra Power Management Controller resume path. On affected Tegra platforms, the kernel calls generic_handle_irq() from a non-interrupt context during resume from system suspend, which is unsafe and can trigger kernel warnings or unstable interrupt handling. The upstream fix defers the call through hard IRQ work using IRQ_WORK_INIT_HARD so generic_handle_irq() executes in the required hard IRQ context, including on PREEMPT_RT kernels. The practical security impact is local denial of service: a local user with the ability to trigger suspend/resume behavior may be able to cause system instability, hangs, or crashes, impacting availability but not confidentiality or integrity.

Why it matters to the business

Affected Tegra-based Linux systems may become unreliable when entering or resuming from suspend, causing service interruptions, device downtime, or operational instability in embedded, edge, robotics, automotive, industrial, or appliance deployments that rely on suspend/resume. Exploitation requires local access and there is no indication of public exploit maturity, KEV listing, ransomware use, or broad remote exploitation, so urgency is lower than internet-facing remote code execution issues; however, availability-sensitive deployments should still prioritize kernel updates during normal maintenance windows.

How an attack unfolds

An attacker first needs local access to an affected Linux system running on a Tegra platform and sufficient ability to induce or repeatedly trigger suspend and resume cycles. During resume, the vulnerable Tegra PMC code path handles wake events and calls generic_handle_irq() from an unsafe non-interrupt context. Because the interrupt handling routine is invoked from the wrong execution context, the kernel can emit warnings and may experience unstable behavior. By repeatedly exercising this path, an attacker could attempt to degrade availability, trigger kernel instability, or cause a denial-of-service condition. The fix changes the resume path so the IRQ handling is deferred into hard IRQ context, preventing unsafe invocation of generic_handle_irq().

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the Tegra PMC resume handler, specifically the change that defers generic_handle_irq() through hard IRQ work using IRQ_WORK_INIT_HARD. Because no exact fixed package versions were provided, obtain patched kernels from the relevant Linux distribution, device vendor, board support package, or NVIDIA Tegra kernel source branch. For embedded or appliance products, request vendor firmware or BSP updates that include this kernel patch. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting the ability of untrusted users or workloads to initiate suspend/resume, disabling unnecessary suspend states on affected devices, and monitoring for repeated suspend/resume failures or kernel warnings. PREEMPT_RT deployments should be treated carefully because the fix explicitly addresses hard IRQ execution requirements under real-time kernels.

How to confirm the fix worked

Confirm the running kernel or vendor BSP contains the Tegra PMC fix that replaces unsafe direct generic_handle_irq() use during resume with hard IRQ work initialized through IRQ_WORK_INIT_HARD. Validate by reviewing vendor changelogs, distribution advisories, kernel source patches, or package metadata for the relevant Tegra PMC change. On representative Tegra hardware, perform controlled suspend/resume testing and verify that kernel logs no longer show warnings from handle_irq_desc, generic_handle_irq, or tegra186_pmc_wake_syscore_resume. Confirm the effective running kernel after reboot with standard OS inventory commands and ensure the patched kernel is the booted kernel, not merely installed. For PREEMPT_RT systems, verify the same test path on the RT kernel configuration because regular IRQ work may otherwise run in threaded context.

Typical attack path

1. Gain local access to an affected Tegra-based Linux system.
2. Confirm the system uses a vulnerable kernel build with the affected Tegra PMC resume code path.
3. Trigger system suspend and resume, either through local power-management interfaces, desktop/session controls, system utilities, or device-specific suspend mechanisms.
4. Cause the Tegra PMC wake-resume path to process wake events and invoke generic_handle_irq() from an unsafe context.
5. Repeat suspend/resume cycles to increase the likelihood of kernel warnings, instability, hangs, or service interruption.
6. Leverage the resulting instability as a local denial-of-service condition.

How to detect it

This issue is primarily a local denial-of-service condition and exploitation may look similar to repeated power-management failures, so detection should focus on kernel logs, audit trails, and power-management events rather than network indicators. Review dmesg, journald, syslog, pstore/ramoops, crash dumps, and kernel oops records for warnings during resume that reference handle_irq_desc, generic_handle_irq, or tegra186_pmc_wake_syscore_resume. Correlate those events with suspend/resume activity from systemd-logind, power-management daemons, desktop session logs, ACPI or platform power events, and command execution logs showing use of systemctl suspend, rtcwake, pm-suspend, or direct writes to /sys/power/state. Investigate patterns where a local user, service account, container, or scheduled job repeatedly triggers suspend/resume shortly before kernel warnings, hangs, watchdog resets, or unexpected reboots. There are no known public threat actors, ransomware campaigns, KEV exploitation, or remote network indicators associated with this CVE based on the provided data.

• WARNING: CPU:
• kernel/irq/irqdesc.c:666
• handle_irq_desc+0x20/0x58
• tegra186_pmc_wake_syscore_resume
• syscore_resume
• suspend_devices_and_enter
• pm_suspend
• generic_handle_irq() is being called from a non-interrupt context
• generic_handle_irq
• /sys/power/state
• systemctl suspend
• pm-suspend
• rtcwake

What your security team should do

• Inventory Linux systems running on NVIDIA Tegra platforms, especially embedded, edge, appliance, robotics, automotive, and industrial devices that use suspend/resume.
• Prioritize remediation for availability-sensitive Tegra deployments and PREEMPT_RT kernel configurations.
• Obtain patched kernel, firmware, or BSP updates from the Linux distribution, device manufacturer, or NVIDIA kernel source provider and schedule deployment through normal change control.
• Until patched, restrict local user access and prevent untrusted users or workloads from initiating suspend/resume cycles.
• Consider disabling suspend or specific low-power states on critical devices where uptime is more important than power savings.
• Monitor kernel logs for suspend/resume warnings involving handle_irq_desc, generic_handle_irq, and tegra186_pmc_wake_syscore_resume.
• After patching, run controlled suspend/resume validation on representative hardware before broad fleet rollout.
• Track vendor advisories because fixed versions may differ across downstream kernels, long-term support branches, and board support packages.