C library vulnerabilities in embedded firmware: glibc, uClibc-ng and musl

Because nearly every user-space program on an embedded Linux device calls into it. Name resolution, environment handling, string conversion, regular expressions and the dynamic loader itself all live in the C library, so one flaw there reaches the web server, the update agent, the BusyBox shell and any vendor daemon at once. The choice is also made very early. The Buildroot manual states that its internal toolchain backend "supports several C libraries: uClibc-ng, glibc and musl", and that changing the type of C library or its configuration usually means a complete rebuild of the whole system. The Yocto Project's TCLIBC variable offers "glibc", "musl", "newlib" or "baremetal". Whatever the SDK or board support package picked at the start tends to stay for the life of the product.

The three libraries differ in more than size:

The libc CVEs that matter most on devices sit in name resolution and in the dynamic loader, because DNS answers come from the network and the loader runs with elevated privileges for setuid programs. Public data, read on 2026-11-12:

CVE-2015-7547 is the reference case for glibc's resolver. The glibc announcement on libc-alpha explains that calling getaddrinfo with the AF_UNSPEC family sends parallel A and AAAA queries, and that buffer mismanagement lets a crafted DNS response write up to 65535 bytes into a 2048-byte stack buffer, with attacker-controlled bytes. The same post lists mitigations that do not work, including options single-request and disabling IPv6, and notes that the flaw lives only in glibc's own copy of libresolv. Any networked device whose programs resolve names through glibc is in scope, which is almost all of them; our dnsmasq vulnerabilities guide covers the resolver that often sits in front of them on the same device.

CVE-2023-4911 shows how the loader becomes an attack surface. The glibc advisory GLIBC-SA-2023-0004 states that a tunable of the form NAME=NAME=VAL passed to a setuid program "may result in a buffer overflow, which could be exploited to achieve escalated privileges", and that the flaw was introduced in glibc 2.34. The Qualys advisory reports full root on default installs of Fedora 37 and 38, Ubuntu 22.04 and 23.04, and Debian 12 and 13, and names Alpine Linux as a notable exception because it uses musl rather than glibc.

The uClibc DNS pair matters because these resolvers sit on small routers and cameras that resolve names constantly. uClibc-ng's fix for CVE-2021-43523, commit 0f822af from August 2021, adds a check of DNS answers for validity "using the same rules glibc does" and shipped in 1.0.39. For CVE-2022-30295, commit f73fcb3 of 10 May 2022 replaced the previous simple counter with configurable query ID generation, random by default where possible, and shipped in 1.0.41. Note that the commit message does not name the CVE, which is typical of how uClibc-ng records security fixes.

The musl iconv and regcomp bugs depend on what the application does. The CVE-2025-26519 advisory says the bug is exposed only when an application opens a conversion from EUC-KR to UTF-8 and feeds it untrusted input, most commonly when the declared charset of XML, HTML or MIME email is passed to iconv_open. The CVE-2026-107891 advisory says an application is vulnerable only if it compiles regular expressions from an untrusted source with the libc regcomp function.

Because each project publishes fixes through a different channel, and scanners see only what reaches a CVE record with a usable version range.

glibc publishes structured advisories. Since 2023 the glibc repository holds a GLIBC-SA advisory per issue; the advisory list read on 2026-11-12 ran from GLIBC-SA-2023-0001 to GLIBC-SA-2026-0028. The advisory format README defines tags for CVE-Id, Public-Date, Vulnerable-Commit and one Fix-Commit per release branch. It also explains a detail that matters for embedded builds: a release-version such as 2.36-118 means the fix is on the release/2.36/master branch "and not in any released tarball". For CVE-2023-4911, the fix is in the 2.39 tarball and on branches 2.34 through 2.38 as commits only, so a device built from the 2.36 tarball stays vulnerable unless the build tracks the branch or applies the commit. The glibc Release wiki page listed release branches 2.32 through 2.44 as maintained when read on 2026-11-12. The glibc security policy also sets out what counts as a security bug, for example that regex denial of service from crafted patterns is treated as a regular bug, which explains why some scanner findings never receive a CVE.

The original uClibc has no fix channel. The uClibc home page states that "uClibc releases are on hold", points to uClibc-ng, and lists 0.9.33.2 from 15 May 2012 as the last release. Every CVE that NVD records against uClibc after that date, such as CVE-2022-30295, has no upstream fix in that codebase.

uClibc-ng fixes in commits and releases. The uClibc-ng project site describes it as a spin-off of uClibc whose main goal is "to provide regulary a stable and tested release", and listed 1.0.60 released on 7 November 2026 as the latest release. The site has news, downloads and a test suite, but no security advisory page. Fixes land as commits that sometimes do not name the CVE, so the version ranges in NVD records are often the only machine-readable link between a CVE and a fixed release.

musl publishes advisories with patches. The musl home page carries a security advisory banner, which on 2026-11-12 listed CVE-2026-107891, CVE-2026-40200 and CVE-2026-6042 as affecting all releases through 1.2.6. The release history gives each CVE's affected range, for example CVE-2026-40200, a stack-based overflow in qsort with large arrays that affects only 32-bit architectures. Fixes are often patches well before a release: the musl 1.2.6 release of 20 March 2026 "includes the fix for CVE-2025-26519 affecting iconv that was previously only available as patches", more than a year after the February 2025 advisory. A version-only scanner therefore flags a correctly patched musl 1.2.5, and cannot see that a 1.2.6 build lacks the regcomp patch unless the CVE range is recorded.

Update within the library's supported line. For glibc, build from the head of the maintained release branch rather than the original tarball, or cherry-pick the Fix-Commit the advisory lists for your branch; for CVE-2023-4911 on 2.36, that is the commit tagged 2.36-118. For uClibc-ng, move to the latest 1.0.x release, which on 2026-11-12 was 1.0.60. For musl, apply the patches attached to each advisory, or move to a release that includes them.

Leave the original uClibc. A product still on uClibc 0.9.x receives no upstream fixes. The uClibc-ng site states that porting applications from glibc to uClibc-ng "typically involves just recompiling the source code", and moving from the original uClibc to uClibc-ng is the shortest path. Moving to musl or glibc is the alternative where the product needs a library with a published advisory process. The Buildroot manual notes that changing the type of C library generally needs a complete rebuild, so plan the switch as a full release.

Use the build system's CVE tooling. The Buildroot manual describes make pkg-stats, whose output includes "whether known CVEs (security vulnerabilities) affect the packages in your current configuration", and the LIBFOO_IGNORE_CVES variable for CVEs fixed by a patch in the package, which must be preceded by a Makefile comment naming the patch. That makes a backport visible to the next scan instead of a silent exception.

Rebuild every static binary. A shared libc update does not touch programs linked statically against an older copy. The CVE-2025-26519 advisory says static binaries that cannot be relinked can be patched by overwriting the EUC-KR charset names in the binary, which disables that conversion entirely; treat that as a stopgap, not a fix.

Rebuild, re-scan, publish. Regenerate the SBOM, compare it with the previous release to confirm every libc copy changed, and publish the affected and fixed versions in your advisory. The SBOM diff tool compares two SBOM files. The same inventory step applies to the other shared components that sit on top of libc; see our BusyBox vulnerabilities, OpenSSL vulnerabilities and Linux kernel CVEs in embedded devices guides.

SoftWSP's scan works from the firmware's software bill of materials. Where the SBOM records the C library as a component with a version, the scan matches that version against CVE records, CISA's KEV catalog and FIRST's EPSS scores, the same deterministic matching it applies to every other component. This part is code: the code scores, and AI narrates.

AI then writes the plain-language summary on top of that matching: which glibc, uClibc-ng or musl CVEs matched, which are KEV-listed or have a high EPSS score, and what the version evidence was. Every sentence cites the component, version and record it relies on, and an engineer reviews every finding before the report is delivered. The judgements this guide describes as manual stay with that engineer: whether the libc family and version were identified correctly, whether a static binary carries an older copy, whether a vendor applied a glibc Fix-Commit or a musl patch behind an unchanged version, and whether a setuid binary or untrusted DNS path makes a CVE reachable. Because matching is version-based, a correctly patched musl 1.2.5 is still flagged for CVE-2025-26519; the review is where the patch evidence turns that flag into a documented not-affected decision.

For where this check fits in a full assessment, see the OWASP Firmware Security Testing Methodology guide, or device & firmware security services to have a specific image reviewed.

This guide draws on the glibc GLIBC-SA advisories, advisory format README, security policy, Release wiki page and 2.34 NEWS, the 2016 libc-alpha announcement of CVE-2015-7547, the Qualys Looney Tunables advisory, the uClibc and uClibc-ng project sites and uClibc-ng commits, the musl home page, release history and Openwall advisories, the Buildroot manual, the Yocto Project reference manual, NVD, CISA's KEV catalog (version 2026.11.10) and FIRST EPSS data dated 2026-11-10, all read directly on 2026-11-12.