CVE-2025-38335: Linux gpio-keys fix in PREEMPT_RT and Azure Linux

The Linux kernel fix tracked as CVE-2025-38335 patches a correctness problem in the gpio-keys input driver that could cause a “sleep while atomic”/kernel BUG on PREEMPT_RT (real‑time) kernel builds; Microsoft’s public advisory currently lists Azure Linux as the Microsoft product that includes the affected upstream component, but that product-level attestation is not the same thing as proof that no other Microsoft product could contain the same vulnerable code.

Background / Overview​

The vulnerability description is straightforward and narrowly scoped: when the kernel is built with PREEMPT_RT enabled, a gpio-keys timer callback (gpio_keys_irq_timer) can run in hard‑IRQ context while calling input_event, and that call path takes a spinlock that under PREEMPT_RT becomes an rt_spin_lock — which can provoke a lockdep warning or a kernel BUG because sleeping is not permitted in the observed atomic context. The upstream remediation relaxes the timer’s expectation about running in hardirq context (deferring to a context that can safely acquire the required locks), eliminating the illegal sleep/lock ordering.

• Component: Linux kernel driver drivers/input/keyboard/gpio_keys.c (gpio-keys).
• Symptom: “BUG: sleeping function called from invalid context” / lockdep assertions when PREEMPT_RT is enabled and the gpio_keys hrtimer path executes.
• Root cause: timer callback context + input_event acquiring a lock that may sleep under RT semantics.
• Fix approach: change/relax the timer expiry/cancellation handling so the callback does not run in a hardirq context that forbids the required locking semantics.

Vendor and public trackers (NVD and multiple distro advisories) consistently describe the issue as a kernel correctness/availability problem tied to PREEMPT_RT-enabled kernels — i.e., the vulnerability vector is local and environment-specific, and the practical exposure is greatest for systems running real‑time kernels or specialized embedded/industrial Linux builds.

---

What Microsoft actually said — and what that wording means​

Microsoft’s MSRC entry for CVE-2025-38335 states that “Azure Linux includes this open‑source library and is therefore potentially affected,” and explains Microsoft’s intent to publish machine‑readable CSAF/VEX attestations (part of a transparency program) and to update the CVE entry if impact to additional products is identified. That language is a product‑scoped inventory attestation: it communicates that Microsoft inspected its Azure Linux artifacts, found the upstream code in those images, and therefore Azure Linux customers should treat those images as in‑scope for remediation.
Parsing that wording carefully leads to two separate, verifiable facts:

• Fact A — Affirmative: Microsoft has confirmed Azure Linux as a Microsoft product that includes the upstream code and therefore Microsoft lists Azure Linux as potentially affected (an authoritative signal for Azure Linux customers).
• Fact B — Negative by omission: Microsoft’s statement does not assert that Azure Linux is the only Microsoft product that could include the code. The MSRC wording is intentionally narrow — a snapshot of the vendor’s inventory work — and Microsoft explicitly says it will update the CVE/VEX records if additional Microsoft products are found to ship the same component. Treat the MSRC entry as a positive confirmation for Azure Linux, not a categorical exclusion of other Microsoft artifacts.

Put succinctly: Azure Linux is the only Microsoft product currently listed by Microsoft as including the affected library, but that listing is a statement of what Microsoft has already checked — not a guarantee that no other Microsoft product could carry the same vulnerable upstream code.

---

Why Microsoft’s product attestation model matters in practice​

Linux kernel code is a build‑time artifact. The same upstream kernel file or driver can appear in multiple different binary kernels depending on three factors:

• Kernel version / commit range (whether the vulnerable commit range is present).
• Kernel configuration (which CONFIG options were enabled at build time; modules vs built‑in).
• Backports or vendor patches (distributors often backport fixes to older kernel branches).

Because of that build‑time variability, a single upstream fix can affect many different distribution kernels and vendor artifacts — but only if those artifacts were compiled with the driver present or built as loadable modules. Microsoft’s inventory attestation for Azure Linux proves Microsoft checked that particular family of artifacts; it cannot, by itself, prove the content of every other Microsoft kernel binary or image.
Examples of other Microsoft artifacts that could contain the same upstream code, depending on how they were built:

• The WSL2 kernel binary that Microsoft publishes (the WSL2 kernel repo and build artifacts are public and Microsoft ships a Microsoft‑maintained kernel for WSL). Whether the WSL2 kernel includes gpio-keys depends on the WSL kernel config.
• CBL‑Mariner-derived images or other Microsoft-built Linux images used for management planes or appliances.
• Marketplace VM images or specialized Azure images that bundle a linux‑azure kernel or other Microsoft kernel artifacts.
• Internal or partner images where Microsoft or partners built a kernel with different config options.

Because Microsoft said it will expand its VEX/CSAF attestations as more inventories finish, absence of those attestations today is not evidence that the artifacts are clean — it simply means they have not yet been attested publicly.

---

Technical verification — what to check and how to confirm whether a given Microsoft artifact includes the vulnerable gpio-keys code​

Artifact-level verification is the only reliable way to determine whether a particular Microsoft product or image is affected. The following checks are practical, quick, and portable across Linux images and kernels.

• Check the machine’s kernel config for gpio and PREEMPT_RT flags:
• grep -i gpio /boot/config-$(uname -r) || zgrep -i gpio /proc/config.gz
• grep -i PREEMPT /boot/config-$(uname -r) || zgrep -i PREEMPT /proc/config.gz
  If CONFIG_GPIO_KEYS (or CONFIG_INPUT_GPIO_KEYS) is set (built‑in: =y or module: =m) and PREEMPT_RT (CONFIG_PREEMPT_RT or a vendor-supplied RT patch) is enabled, the combination is in scope. If PREEMPT_RT is not enabled, the practical risk for this particular CVE is greatly reduced. (This verification approach is the same guidance vendors give for PREEMPT_RT-tied fixes.
• Inspect available modules / modules.vhdx (in managed or appliance images):
• modinfo gpio_keys
• lsmod | grep gpio_keys
  If a loadable module named gpio_keys exists in the running kernel modules set, it is a candidate for being the implicated driver.
• Inspect kernel boot logs for the stack trace / error:
• dmesg | grep -i "sleeping function called" -A10
• dmesg | grep -i gpio_keys -A10
  The canonical dmesg trace showing "in_atomic: 1, irqs_disabled: 1" and the stack frames through input_event and gpio_keys_irq_timer indicates the runtime manifestation that motivated the upstream patch.
• For WSL or other Microsoft-distributed kernels that are published (WSL2 kernel repo), review the kernel config file in the published repo and the Microsoft config-wsl to see whether the option is enabled; Microsoft publishes the WSL kernel source and a configuration template that can be inspected. If you run WSL with a custom kernel, check that custom config.
• If you manage images centrally (cloud automation / image pipelines), compare the kernel package version or kernel config artifact used to build the image against the upstream fix commit range. If the kernel version is older than the stable branches that received the gpio-keys fix, plan to patch or build a backport.

If any of the above checks confirm the presence of gpio-keys plus PREEMPT_RT in a Microsoft artifact you run, that artifact should be treated as in‑scope for patching even if Microsoft has not yet explicitly attested to it.

---

Practical mitigation and remediation guidance​

• For Azure Linux: follow Microsoft’s Azure Linux updates and apply the patched kernel images as Microsoft publishes them. Microsoft’s attestation means Azure Linux images are a confirmed priority.
• For WSL2 users: Microsoft maintains the WSL2 kernel and publishes updates; ensure Windows and WSL are updated through Microsoft Update and the WSL update mechanisms. If you run a custom WSL kernel or custom modules, rebuild or inspect the kernel configuration and backport the kernel patch if necessary.
• For any other Microsoft-supplied kernel (Marketplace images, CBL‑Mariner derivatives, device images): perform artifact verification (kernel config, module presence, dmesg traces) and patch or rebuild the kernel to include the upstream stable fix or a vendor backport.
• Short-term mitigations if you cannot patch immediately:
• Avoid running PREEMPT_RT‑enabled kernels on multi‑tenant hosts until patched.
• Restrict untrusted workloads from loading or manipulating BPF/timer-driven workflows that can exercise the gpio-keys timer path (the attack surface is local and, in practice, tied to specific local operations).
• Add dmesg/syslog monitors for the lockdep / “sleeping function called from invalid context” traces and prioritize remediation for hosts that log the trace.

---

Risk analysis — who should worry most​

• Highest risk: systems that run PREEMPT_RT (real‑time) kernel builds and include the gpio-keys driver (embedded devices, industrial controllers, specialized telecom or real‑time appliances). Those environments can experience kernel BUGs and availability problems if vulnerable kernels are used.
• Moderate risk: cloud images or VMs that include kernel builds compiled with RT patches or with broad kernel config options that enable gpio drivers and input subsystems. In cloud or multi‑tenant environments, a local kernel BUG can have outsized availability impacts.
• Low risk: standard desktop/server distributions running non‑PREEMPT_RT kernels and with gpio input drivers compiled out or never loaded under the runtime environment — the PREEMPT_RT dependency narrows the practical exposure substantially.

Operational severity should be considered availability‑first: this is a correctness/lock ordering bug that produces kernel BUGs and potential host instability rather than a confirmed remote code execution primitive. That said, kernel panics and host-level denial‑of‑service events in shared infrastructure are real operational hazards and should be remedied promptly when vendors publish fixes.

---

Cross‑verification and independent evidence​

• Upstream kernel stable commit listings and public patch threads record the gpio-keys change and the rationale (relax the hrtimer not to use hard context). The stable patch series and spinics/lore posts show the same patch summary and code hunks that address the issue.
• Public vulnerability databases (NVD, CVE aggregators) describe the same technical detail and explicitly note the PREEMPT_RT dependency in the vulnerability summary. These independent trackers confirm the scope and remediation approach recommended by upstream.
• Microsoft’s MSRC text is an authoritative product attestation for Azure Linux; it states Microsoft’s CSAF/VEX rollout and commitment to expand attestation coverage if additional Microsoft products are found to include the vulnerable upstream code. The MSRC wording therefore corroborates Microsoft’s inventory-first, phased approach.

Where a claim cannot be verified: it is not possible from Microsoft’s Azure Linux‑scoped attestation alone to prove or disprove whether other Microsoft products currently include gpio-keys. That question is inherently artifact‑specific and must be resolved by inspecting the kernel binaries/configurations or waiting for Microsoft’s VEX/CSAF attestations to be expanded. The safest operational response is to assume unverified Microsoft artifacts are “unknown” until confirmed clean.

---

Practical checklist for administrators (short checklist)​

• If you run Azure Linux images — apply Microsoft’s Azure Linux kernel updates as soon as they become available.
• For each Microsoft-provided kernel artifact you run (WSL, Marketplace images, CBL‑Mariner derivatives, custom images), perform artifact-level verification:
• Inspect kernel config (grep for CONFIG_GPIO_KEYS and PREEMPT_RT).
• Check module list (modinfo / lsmod).
• Scan dmesg for the characteristic trace.
• If PREEMPT_RT is enabled and gpio-keys is present, prioritize patching or backporting the upstream fix.
• Monitor logs and automation: add dmesg/generic OOPS detectors for “sleeping function called from invalid context” on your fleet.
• Track Microsoft’s VEX/CSAF updates for CVE‑2025‑38335 and other vendor advisories; apply vendor patches or rebuild kernels when manufacturers or distributors publish backports.

---

Conclusion​

CVE-2025-38335 is a narrowly scoped Linux kernel correctness fix for the gpio-keys input driver that matters in practice only for kernels built with PREEMPT_RT and where the driver is present. Microsoft’s MSRC advisory correctly and transparently confirms that Azure Linux includes the upstream code and should therefore be treated as potentially affected; that attestation is authoritative for Azure Linux customers. However, Microsoft’s phrasing does not and cannot prove that no other Microsoft product contains the vulnerable code — the presence of kernel code is a build‑time artifact that must be verified per product image. Customers running other Microsoft-provided kernels (for example WSL2 kernels, Marketplace images, and image families derived from Microsoft build systems) should perform the artifact-level checks described here and treat any image that includes gpio-keys + PREEMPT_RT as in‑scope for remediation until proven otherwise.
Practical next steps remain clear: prioritize Azure Linux updates, inventory other Microsoft kernel artifacts in your estate, verify kernel configs/modules for gpio-keys and PREEMPT_RT, and apply vendor patches or backports where needed. The upstream patch and vendor advisories are available now; act on artifacts you control and watch Microsoft’s VEX/CSAF updates for additional product attestations.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center