qsort stack corruption in musl risks 32-bit code execution

TL;DR — musl libc’s qsort can write past a stack buffer on 32-bit builds when sorting sufficiently large inputs, leading to crashes and potentially code execution.

What happened

musl is an implementation of the C standard library; it provides core libc functionality (including qsort) used by C/C++ applications and system components.

An oss-security disclosure for CVE-2026-40200 reports that musl’s qsort implementation may write past the end of a stack-based buffer once the number of elements being sorted exceeds a threshold (reported as “beyond 7 million elements” on 32-bit systems). On 64-bit systems, the threshold is reported as “exceeding 34 trillion” elements, which the post describes as not practical.

The report states impact is not yet determined, but at minimum includes a crash, with possible code execution on 32-bit systems. The post also notes that exploitation risk is elevated by the presence of indirect calls to a comparison function in the affected code path and advises treating this as a high-risk memory-safety issue until proven otherwise.

Who is impacted

• Any deployment using musl libc versions 0.7.10 through 1.2.6 (the disclosure states the vulnerable code has been present since 0.7.10, and that all subsequent versions up through 1.2.6 are affected).
• Primarily 32-bit systems where attacker-controlled or untrusted inputs can cause qsort to run over arrays with more than ~7 million elements.
• 64-bit systems are described as not practically affected unless they can reach extremely large element counts (reported as “exceeding 34 trillion”).

What to do now

• Follow upstream remediation guidance. The disclosure states:

  "All users should apply the patch included/attached below, or upgrade to 1.2.7 once it becomes available."

• Inventory where musl is in your fleet (base images, container OS, embedded userspace) and identify any 32-bit deployments running versions in the affected range.
• Triage application paths that invoke qsort over attacker-influenced datasets (e.g., parsing, request-driven indexing/sorting, or untrusted file formats) where element counts could be driven into the vulnerable range.
• If you cannot immediately apply the patch or consume a fixed musl build, consider reducing exposure by ensuring untrusted inputs cannot trigger extremely large qsort element counts in 32-bit processes (e.g., input size limits and defensive bounds checks in calling code).