CVE-2026-43108

What it actually does

This flaw is a local denial-of-service issue in the Linux kernel Qualcomm SoC pd-mapper service registry handling. A mismatch between the declared element length in servreg_loc_pfr_req_ei and the actual reason field in servreg_loc_pfr_req can cause QMI string decoding failures during protection-domain crash handling. On affected systems using the Qualcomm pd-mapper path, a local user with the ability to trigger or influence the relevant crash/notification path may cause kernel-side decoding errors that can disrupt availability. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can cause affected Linux systems, particularly Qualcomm-based platforms using this kernel component, to become unstable or unavailable. The most likely operational consequence is service interruption, device reboot, or impaired platform functionality rather than data theft. Public exploitation signals are currently low: EPSS is 0.00114 with no 30-day increase, it is not listed in CISA KEV, and no mature public exploit is indicated. However, kernel availability bugs should still be addressed through normal patch management because they can affect critical embedded, mobile, edge, or appliance workloads when the vulnerable driver path is present.

How an attack unfolds

An attacker first needs local access to an affected Linux system and sufficient low-privileged execution context. They then attempt to reach the Qualcomm pd-mapper/service-registry code path involved in protection-domain crash handling. By causing or interacting with a condition that supplies an unexpected reason string length, the vulnerable QMI decoder observes a string length that exceeds the expected maximum, producing an error such as 'qmi_decode_string_elem: String len 81 >= Max Len 65'. Because this occurs in kernel component handling for Qualcomm service registration/protection-domain events, repeated triggering can degrade system reliability or cause a denial of service. There is no indication from the provided data that the flaw enables remote compromise, privilege escalation, data exfiltration, or code execution.

How to fix it

Apply a Linux kernel update from the system, device, SoC, or distribution vendor that includes the upstream fix for the Qualcomm pd-mapper servreg_loc_pfr_req_ei element length mismatch. No exact fixed package versions were provided, so track vendor advisories for the affected kernel branch and upgrade to the first available patched kernel or later. Where immediate patching is not possible, reduce local attack surface by limiting shell access, untrusted local workloads, container escape opportunities, and access to interfaces that can interact with Qualcomm protection-domain/service-registry behavior. For embedded or appliance products, request patched firmware or BSP updates from the vendor and prioritize devices where availability loss would be operationally significant.

How to confirm the fix worked

Confirm the running kernel or vendor firmware includes the patch that aligns the servreg_loc_pfr_req_ei reason element length with the servreg_loc_pfr_req reason field. Validate by checking vendor package changelogs, kernel source patches, distribution CVE trackers, or firmware release notes for this specific fix. On source-based builds, inspect the Qualcomm pd-mapper implementation to verify the element length definition matches the referenced request structure. After patching, reboot into the updated kernel and confirm the active kernel version is the patched one. Review kernel logs before and after remediation for recurring QMI decode errors involving string length exceeding maximum length; absence of those errors under previously triggering conditions supports successful remediation.

Typical attack path

1. Obtain local execution on an affected Linux system, typically as a low-privileged user or local process.
2. Determine whether the system uses the Qualcomm SoC pd-mapper/service-registry kernel path.
3. Trigger or influence a protection-domain crash or service-registry notification path that reaches servreg_loc_pfr_req_ei decoding.
4. Cause the malformed or length-mismatched reason field handling to produce QMI decode errors.
5. Repeat the trigger to disrupt system availability, potentially causing service instability, device malfunction, or reboot.

How to detect it

To determine whether this was already exploited or triggered, review kernel and system logs for Qualcomm pd-mapper, service registry, protection-domain, or QMI decoding errors. Relevant sources include journalctl kernel logs, dmesg, /var/log/kern.log, /var/log/messages, Android or embedded device kernel logs where applicable, crash dumps, watchdog reset records, and device uptime/reboot telemetry. Look for repeated QMI string decode failures, especially messages showing a string length exceeding maximum length during PD crash handling. Correlate those events with local user sessions, newly launched processes, container workloads, device crashes, watchdog resets, or unexpected reboots. Because this issue does not have a known remote network signature and no public exploit maturity is indicated, detection should focus on local kernel log artifacts and abnormal availability events rather than network IOCs.

• qmi_decode_string_elem: String len 81 >= Max Len 65
• qmi_decode_string_elem: String len
• Max Len 65
• servreg_loc_pfr_req_ei
• servreg_loc_pfr_req
• pd-mapper
• qcom: pd-mapper
• protection domain crash
• PD crash
• QMI decode

What your security team should do

• Prioritize patching affected Qualcomm-based Linux systems through the normal kernel or firmware update process, especially systems where local users or untrusted workloads are present.
• Inventory Linux devices and appliances that use Qualcomm SoCs or include the pd-mapper/service-registry kernel component.
• Monitor vendor kernel, firmware, BSP, and distribution advisories because exact fixed versions were not provided in the input data.
• Treat this as an availability-risk vulnerability rather than a data-breach vulnerability; prioritize business-critical systems where downtime has high impact.
• Restrict local access and untrusted code execution on affected systems until patched.
• Add monitoring for kernel log messages indicating QMI decode failures, especially repeated occurrences that may indicate attempted triggering.
• Because EPSS is low, stable, and the issue is not in CISA KEV, handle through risk-based patch cycles unless the affected device class is safety-critical, production-critical, or internet-exposed through services that allow local code execution.