CVE-2026-43345

What it actually does

This flaw is a Linux kernel availability issue in the IPA/GSI networking subsystem. For IPA v5.0 and later hardware, the event ring index is programmed into the wrong channel context register field, leaving GSI channels without a valid event ring for transfer completion signaling. As a result, kernel code waiting for channel transfer quiescence can block indefinitely in wait_for_completion(), causing IPA data path failure and hangs during runtime suspend, system suspend, or remote processor shutdown. The described impact is denial of service rather than data disclosure or integrity compromise.

Why it matters to the business

Systems that depend on the affected Linux kernel IPA driver can lose network data path functionality or hang during suspend, power-management transitions, or remote processor stop operations. In operational terms, this can cause device freezes, failed suspend/resume cycles, service interruption, increased support burden, and potential fleet instability. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no known public exploit maturity, so remediation should be prioritized based on exposure of affected hardware and operational criticality rather than active exploitation pressure.

How an attack unfolds

An attacker would need to cause the affected IPA/GSI driver path to initialize or operate in a state where GSI channel transfer completion signaling is required but the event ring index has not been correctly programmed for IPA v5.0+ hardware. Once the vulnerable path is exercised, transfer completions are not delivered through the expected event ring. Kernel execution then waits indefinitely for completion during channel quiesce operations, which can occur during runtime suspend, system suspend, or remote processor stop. The practical outcome is a denial-of-service condition: the IPA data path can become nonfunctional and the system or subsystem can hang. There is no indication from the supplied data that this flaw enables code execution, privilege escalation, credential theft, or data tampering.

How to fix it

Apply a Linux kernel version or vendor kernel update containing the IPA fix for the event ring index field on IPA v5.0+ hardware. Because no exact fixed versions were provided, obtain the corrected kernel from the operating system, device, silicon, or appliance vendor and verify that the patch for 'net: ipa: fix event ring index not programmed for IPA v5.0+' is included. Where immediate patching is not possible, reduce risk by disabling or avoiding affected IPA hardware/driver functionality where operationally feasible, limiting exposure of devices that rely on the affected data path, and avoiding automated suspend or remoteproc stop workflows that are known to trigger hangs until patched.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes IPA/GSI support and whether the platform uses IPA v5.0 or later hardware. Validate remediation by confirming the vendor kernel package or source tree includes the corrected CH_ERINDEX field placement for IPA v5.0+ in the IPA register definitions. Operationally test runtime suspend, system suspend/resume, remoteproc stop/start, and IPA data path traffic after patching; successful remediation should eliminate indefinite hangs in gsi_channel_trans_quiesce() and restore normal completion signaling. Also review kernel logs for absence of repeated IPA/GSI suspend, remoteproc, or completion timeout symptoms after the update.

Typical attack path

1. Identify a Linux-based device using an affected kernel with IPA v5.0 or later hardware support enabled.
2. Trigger network, modem, power-management, suspend/resume, or remote processor activity that exercises IPA/GSI channel setup and quiesce paths.
3. Cause or wait for a condition requiring GSI transfer completion signaling through the affected event ring.
4. The kernel fails to receive the expected completion because the event ring index was programmed incorrectly.
5. The affected kernel thread or subsystem blocks indefinitely in wait_for_completion(), causing IPA networking failure, suspend failure, or a broader device hang.

How to detect it

To determine whether this issue was already triggered, review kernel logs, persistent journal data, crash dumps, watchdog resets, and device health telemetry for hangs or blocked tasks involving IPA, GSI, remoteproc, runtime suspend, or system suspend. Useful sources include dmesg, journald, /var/log/kern.log, /var/log/messages, pstore/ramoops, kernel panic reports, watchdog reset records, and mobile or embedded platform diagnostic logs. Look for repeated suspend/resume failures, remoteproc stop operations that never complete, IPA data path initialization failures, hung task warnings referencing gsi_channel_trans_quiesce() or wait_for_completion(), and watchdog resets shortly after network, modem, or suspend activity. There are no supplied indicators of malicious exploitation, so detection should focus on reliability artifacts consistent with the vulnerable code path being exercised rather than attacker-specific signatures.

• gsi_channel_trans_quiesce
• wait_for_completion
• IPA data path
• remoteproc stop
• runtime suspend
• system suspend
• hung task
• blocked for more than
• gsi_channel
• ipa
• remoteproc
• /sys/kernel/debug/ipa
• /sys/kernel/debug/gsi
• /sys/fs/pstore
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Inventory Linux systems and embedded devices that use Qualcomm IPA/GSI networking hardware, especially platforms using IPA v5.0 or later.
• Prioritize patching for devices where suspend/resume reliability, modem connectivity, or remote processor lifecycle management is business-critical.
• Request vendor confirmation of the kernel fix if exact fixed package versions are not available in public advisories.
• Monitor kernel logs and device health telemetry for suspend hangs, remoteproc stop failures, IPA data path failures, and blocked kernel tasks involving IPA or GSI functions.
• For unpatched systems, consider operational workarounds such as disabling affected suspend states or avoiding workflows that repeatedly stop remote processors, if acceptable for the device use case.
• Because there is no KEV listing, no known ransomware use, low EPSS, and no known exploit maturity in the supplied data, treat this primarily as a reliability and availability patching item unless affected systems are exposed in high-impact services.