CVE-2024-26902: Linux RISCV PMU Panic and Azure Linux Attestation

CVE-2024-26902 exposes a narrowly scoped but real risk in the Linux kernel’s RISC‑V performance monitoring path: a coding error in the PMU overflow handler can, under specific conditions, trigger a NULL pointer dereference and kernel panic. Microsoft’s published advisory for this CVE calls out Azure Linux as a product that “includes this open‑source library and is therefore potentially affected,” but that statement is a product‑scoped inventory attestation — useful and authoritative for Azure Linux customers, yet not definitive proof that no other Microsoft product could carry the same vulnerable code.

Background / Overview​

CVE-2024-26902 was assigned to a Linux kernel bug described upstream as “perf: RISCV: Fix panic on pmu overflow handler.” The root cause is straightforward in C terms: the code sets bits in an unsigned long bitmap using an expression that evaluates as a signed int shift (1 << idx) rather than the correct BIT() macro or an unsigned long literal. On RISC‑V platforms where the PMU and perf event handling are active, the incorrect bit operations can corrupt state used by the overflow handler and cause a NULL pointer dereference in an interrupt context — which, in the kernel, typically results in an immediate panic and host unavailability.
The condition that surfaces the bug is specific: it was observed while running the perf tooling (for example, perf record -e branches) on certain RISC‑V hardware (reported on the Sophgo SG2042 / “Sophgo Mango” reference hardware). Because the failure occurs in an interrupt handler, the practical consequence is an availability impact (kernel panic / system crash) rather than data disclosure or integrity compromise. Multiple distribution trackers and security databases record the issue and the upstream fix.

---

What exactly went wrong (technical summary)​

• The bug sits in the RISC‑V PMU overflow code path that handles performance monitoring interrupts (PMI).
• A per‑CPU or per‑device bitmap (commonly named something like overflowed_ctrs) is updated to mark which counters overflowed.
• The code used a literal integer left shift (1 << idx) when setting a bit in an unsigned long map. On platforms where sizeof(int) is smaller than the width used to represent counter masks, that expression can produce an unexpected value and clear or corrupt indexes used later by the overflow handler.
• The downstream effect — when certain indexes are touched — is an access through a NULL or otherwise invalid pointer in riscv_pmu_ctr_get_width_mask or the overflow handler, producing a kernel oops and panic. The crash signatures seen in multiple reports show a badaddr of 0x98 and traces into riscv_pmu_ctr_get_width_mask and pmu_sbi_ovf_handler.

This is a classic example of why using explicit-width macros (BIT(), BIT_ULL(), or 1UL << idx depending on intent) matters in kernel code that must be portable across builds and architectures.

---

How broadly does this CVE matter?​

Short technical answer: the bug is architecture‑specific (RISC‑V PMU path) and operationally triggered by perf usage; it is not a generic remote code execution issue. That reduces the immediate blast radius compared with privilege‑escalation or remote‑RCE CVEs. However, the impact is availability: a kernel panic in a host or VM running a RISC‑V kernel with the unpatched code can cause service outages for that system.
From a supply‑chain and product‑scope perspective, there are two separate questions:

• Which upstream kernel versions contained the vulnerable code? Distribution trackers list the affected ranges and the commits that patch the bug; vendors and packagers should consult their kernel changelogs to see whether their shipped kernel includes the fix. Distributors such as Ubuntu and Debian include CVE pages that list the issue details and remediation status.
• Which products and artifacts include an affected kernel tree or build? Microsoft’s published statement for this CVE explicitly attests that Azure Linux includes the implicated open‑source component and is therefore potentially affected. That attestation is the result of Microsoft’s inventory work for that product; Microsoft has said it will expand its machine‑readable CSAF/VEX attestations if other Microsoftdentified as carriers. The important nuance is that an attestation naming Azure Linux is authoritative for Azure Linux — but it does not, by itself, categorically rule out other Microsoft artifacts.

---

Microsoft’s wording: what “Azure Linux includes … and is therefore potentially affected” means in practice​

Microsoft’s phrasing is concise and deliberate. It communicates three things:

• Microsoft has performed a product inventory for Azure Linux and found the affected upstream code in that product’s kernel/artifact.
• As a result, Azure Linux customers should treat the CVE as relevant and take remediation steps when Microsoft publishes fixes or updated images.
• Microsoft is not claiming — in that single line — that no other Microsoft product includes the same code. The statement is a product‑scoped status update. Microsoft has also committed to publish machine‑readable VEX/CSAF attestations (a transparency initiative rolled out starting with Azure Linux) and to update the CVE mapping if more Microsoft products are found to ship the vulnerable component.

Security practitioners should therefore read the advisory as authoritative yes for Azure Linux and not yet checked for other Microsoft SKUs until Microsoft (or independent verification) demonstrates otherwise. Numerous community analyses of Microsoft’s VEX/CSAF rollouts emphasize the same reading: product‑level attestations are valuable, but absence of an attestation is not definitive proof of absence.

---

Is Azure Linux the only Microsoft product that could be affected?​

No — not necessarily. The presence of the vulnerable kernel code upstream means any Microsoft product that ships a Linux kernel build containing the same sources and build-time configuration (i.e., RISC‑V PMU support enabled, perf event bits enabled, relevant drivers compiled in) could carry the bug.
Potential Microsoft carriers beyond Azure Linux include, but are not limited to:

• WSL2 kernel builds and kernel images distributed with WSL‑related packages.
• linuel packages used by cloud VM images.
• Marketplace VM and appliance images that include a custom kernel.
• Any Microsoft distribution or device image that imports and ships a kernel tree containing the vulnerable perf/riscv code path.

Whether a given product is actually vulnerable depends on the per‑artifact kernel build configuration and whether the hardware is RISC‑V. In other words, code presence alone is necessary but not sufficient to prove exploitable exposure.

---

Cross‑checking the technical facts (why this matters for defenders)​

To meet the bar for rigorous verification, I cross‑checked the core technical claims with multiple independent sources:

• The NVD entry for CVE‑2024‑26902 documents the upstream description, crash trace characteristics, and the code pattern (1 << idx vs BIT()). That is the primary canonical CVE text used by many downstream trackers.
• Distribution security pages (Ubuntu, Debian trackers) list the CVE, give a CVSS score (Ubuntu lists CVSS 5.5 / Medium), and tie out the observed impact (kernel panic / availability). These sources confirm how distributions scored the issue and the remediation guidance they published.
• Multiple vulnerability databases and vendor advisories (Rapid7, Tenable, CVE‑Details) independently record the bug and note the same root cause and symptom set (overflowed_ctrs bit handling and kernel NULL deref in riscv_pmu code). Cross‑referencing these pages reduces the chance of a mistaken technical interpretation.

Where one source offered a version or remediation window (for example, references to kernel versions where the fix was applied), I compared that claim to distribution changelogs and upstream kernel commit summaries. If you are responsible for patching, always validate the exact patched commit(s) in your distribution’s kernel changelog and use the vendor’s backport notes: different vendors backport fixes into different kernel trees and release channels.

---

Practical recommendations for system operators​

If you run any Linux artifacts in your estate — and especially if you run RISC‑V hosts, VMs, or emulated images — treat the issue with appropriate priority for availability‑impact bugs. Specific steps:

• Inventory
• Identify all machines and artifacts that run Linux kernels built for RISC‑V or that could be running a RISC‑V‑capable kernel. Use standard discovery tools and asset inventories.
• Make a minimal risk list of Microsoft‑supplied artifacts in your estate: Azure Linux images, WSL2 kernels, Marketplace images, linux‑azure kernels, and container host images.
• Verify presence
• On a candidate host, check the running kernel version: uname -r.
• Confirm whether the kernel tree includes RISC‑V PMU/perf support. On many systems, inspect kernel config (zcat /proc/config.gz or check /boot/config-$(uname -r)) for CONFIG_PERF_EVENTS and architecture-specific PMU options. Grep config for ARCH_RISCV or RISCV_PMUs where appropriate.
• If you cannot access config, query modules and dmesg for riscv PMU traces or check for the presence of the pmu driver in the firmware/driver list.
• Patch or mitigate
• Apply vendor‑supplied kernel updates. Distributors and vendors that shipped the vulnerable code should publish patched kernel packages or updated images. For Azure Linux customers, follow Microsoft’s patch guidance and replace affected images or apply the updated kernel package Microsoft provides.
• If an immediate vendor patch is not available for a high‑value host, consider temporary mitigations: disabling perf collection on the host, restricting access to perf tooling to trusted admins, or disabling the offending PMU support where feasible (note: disabling PMU support may not be possible without a rebuild or could reduce diagnostic capability).
• Monitor vendor attestations and advisories
• Microsoft has started publishing CSAF/VEX attestations (machine‑readable) beginning with Azure Linux; those attestations are intended to make product mappings explicit. If Microsoft updates the CVE page to add more products, act according to the new mapping.
• Communicate with stakeholders
• For production clusters or cloud services, label the issue as an availability risk and coordinate scheduled maintenance windows to apply patched kernels.

---

How to check whether your Microsoft artifacts are affected (practical commands)​

• Check kernel release and distro:
• uname -a
• cat /etc/os-release
• Check kernel config (if available):
• zcat /proc/config.gz | grep -i 'PERF|PMU|RISCV'
• grep -i 'perf' /boot/config-$(uname -r) || zgrep -i 'perf' /proc/config.gz
• Look for perf usage and setuid perf tools:
• which perf
• ls -l $(which perf) (restrict perf to root where possible)
• Audit package/kernel version against vendor advisories:
• For Azure Linux images, compare your kernel package version to the patched versions Microsoft publishes in the Azure Linux announcement or image update notes.
• For distro kernels, consult your distributor’s CVE page (Ubuntu, Debian, etc.) to see whether the kernel package you run is listed as fixed.

These checks help you move from speculation to confirmed presence or absence of the vulnerable code in a specific host or artifact.

---

Risk rating and exploitation complexity​

• Impact class: Availability (kernel panic / system crash).
• Exploit complexity: Moderate — the issue requires local execution context and interaction with perf event handling on RISC‑V hosts. It is not a straightforward remote, unauthenticated exploit.
• Likelihood / blast radius: Limited to RISC‑V systems and to artifacts that ship the affected PMU code and have perf enabled. That said, RISC‑V adoption is growing in specialized markets and cloud/edge appliances; for organizations using RISC‑V systems, the issue is material.
• CVSS guidance: Several trackers record a CVSS v3.1 base score of 5.5 (Medium) for this CVE, reflecting local attack vector with high availability impact. Use vendor guidance for your risk model.

---

Supply‑chain and disclosure context: Microsoft’s CSAF/VEX rollout​

Microsoft’s public approach to third‑party CVEs has evolved: after standardizing on CSAF for machine‑readable advisories, Microsoft announced a phased rollout of Vulnerability Exploitability eXchange (VEX) attestations starting with Azure Linux in October 2025. The goal is to produce crisp, per‑product attestations (Not Affected / Under Investigation / Known Affected / Fixed) so customers and security vendors can automate risk decisions. Microsoft’s single‑product attestation for many CVEs is part of that phased approach. That means:

• Azure Linux has been the first Microsoft product to receive these VEX/CSAF attestations, so it often appears as the one named product in early advisories.
• Microsoft has committed to expanding those attestations to other products where the inventory work identifies carriers of the same open‑source components.

This transparency work is welcome, but defenders must remain pragmatic: treat an attestation as definitive for the named product, and treat other Microsoft artifacts as not yet attested until Microsoft publishes an explicit mapping or you independently verify presence.

---

Strengths and limitations of Microsoft’s public attestation approach​

Strengths:

• Clarity for customers: A named attestation (e.g., “Azure Linux includes this library”) lets Azure Linux operators prioritize and apply patches quickly.
• Machine readability: CSAF/VEX enables automation for large enterprises and security vendors, reducing noise from false positives.
• Commitment to expand: Microsoft’s VEX roise to update mappings if more products are affected, which is an operationally realistic model.

Limitations / Risks:

• Perception gap: Customers unfamiliar with supply‑chain nuance may read a single‑product attestation as an exclusivity guarantee — it is not. The wording must be interpreted as a product‑scoped inventory statement.
• Inventory lag: The underlying effort — mapping upstream components into dozens of products and images — is substantial. Until Microsoft completes inventory work across all product lines, some carriers may remain un‑attested.
• Artifact diversity: Microsoft (like other large vendors) ships multiple, independently built kernel artifacts. A vulnerability in upstream code can appear in several places, depending on build choices and backport decisions.

The pragmatic defensive posture is therefore: act on Microsoft’s attestation for Azure Linux immediately, but also scan and verify your other Microsoft‑supplied artifacts rather than assuming they are safe by omission.

---

Conclusion: what defenders should take away​

CVE‑2024‑26902 is a real but narrowly focused kernel panic bug in the RISC‑V perf PMU handler. It requires RISC‑V hardware and perf activity to trigger and produces an availability impact. Microsoft has published an attestation naming Azure Linux as a product that includes the implicated open‑source component and is therefore potentially affected — an authoritative statement for Azure Linux customers that should prompt immediate remediation where applicable. However, that attestation is product‑scoped: it is not a global guarantee that no other Microsoft product could contain the same vulnerable code. Treat un‑attested Microsoft artifacts as “not yet checked” and perform artifact‑level verification across your estate.
Operational checklist:

• Inventory RISC‑V hosts and Microsoft‑supplied Linux artifacts in your estate.
• Verify kernel versions and build configurations (perf / PMU).
• Apply vendor patches or updated images as soon as they are available.
• Restrict perf usage to trusted admins until systems are patched.
• Monitor Microsoft’s CSAF/VEX feed and your distribution advisories for updates.

Cross‑referenced technical sources for this analysis include the NVD and distribution trackers (which document the failure signatures and root cause), multiple vulnerability databases confirming the fix and symptom set, and Microsoft’s public attestation and transparency blog describing the CSAF/VEX rollout. Those references collectively confirm the vulnerability description, the practical remediation path, and the interpretation of Microsoft’s attestation language.
If you manage Azure Linux images or any Microsoft‑supplied Linux artifacts, treat this CVE as actionable for Azure Linux now — and verify other Microsoft images in your environment rather than assuming they are unaffected by omission.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center