Repository navigation
alsa-lib: backport CVE-2026-90781 fix, declare GithubRepo provenance - #915
Conversation
CVE-2026-90781 is a one-byte stack overrun in __snd_ctl_ascii_elem_id_parse (src/control/ctlparse.c) when parsing a name= field of 64 or more characters. It affects every release through 1.2.16.1, which is what we ship and is still the latest. Upstream fixed it in alsa-project/alsa-lib f84cd4ced7b3 (unreleased). Debian carries the same commit as 1.2.16.1-2. - Carry the verbatim upstream commit as CVE-2026-90781.patch, applied with `patch -Np1` under `set -e` so a stale patch fails the build. - Add a build-time regression test. It compiles ctlparse.c under AddressSanitizer and parses 100-character quoted and unquoted names. Negative control: with the patch skipped, ASan reports stack-buffer-overflow at ctlparse.c:239 and the build fails. - Declare source_provenance GithubRepo alsa-project/alsa-lib. alsa-lib had none, so the advisory pipeline never asked about it (pkgmgr-rs#848). Refs gominimal/pkgmgr-rs#848 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reached
This review includes 4 billable files and costs up to $1.00.
Reviews can continue after your included limit without a manual trigger. An admin must approve usage-based billing. Or wait 15 minutes for your next included review. View limit details
Comment |
There was a problem hiding this comment.
The carried patch matches upstream f84cd4ced7b3 and applies cleanly, but it leaves one of the three overrun sites unfixed.
f84cd4ce's message says "Follows 1e27d63ef6d1". 1e27d63e ("Fix theoretical one-byte buffer overrun") fixes the same one-byte buf[64] overrun on the numid= branch, and it is not an ancestor of v1.2.16.1 (checked with git merge-base). In the packaged source, src/control/ctlparse.c:~176 still has if (size < (int)sizeof(buf)) under numid=. The patch still applies because its hunks don't touch that site.
Requested:
- Carry
1e27d63etoo. - Extend the ASan test (
build.sh:45-55) with a long (~100 char)numid=value. It currently only exercisesname=.
The provenance (alsa-project/alsa-lib is upstream's own org) and the ASan harness (never installed, fails closed) look good.
Generated by Claude Code
f84cd4ce says it "follows 1e27d63ef6d1", which fixes the same one-byte overrun of buf[64] on the numid= branch of __snd_ctl_ascii_elem_id_parse. 1e27d63e is not an ancestor of v1.2.16.1, so f84cd4ce alone left that site open. Carry it verbatim (git format-patch) and extend the ASan regression test with a 100-digit numid=. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Thanks @norrietaylor, good catch. Both are in 027f975 (on top of a merge of main):
The PR body is updated to match. 🤖 Generated with Claude Code |
There was a problem hiding this comment.
Thanks, this addresses it.
-
The new patch matches upstream
1e27d63ef6d1exactly (apart from the format-patch signature line, which is cosmetic). Both patches apply cleanly to 1.2.16.1 in either order, and all three copy loops inctlparse.cnow bound bysizeof(buf) - 1. -
I re-ran the
build.shtest block against each combination of patches:- both: passes;
- neither: stack-buffer-overflow;
- f84cd4ce only: fails at
ctlparse.c:182(numid); - 1e27d63e only: fails at
:239.
So the new
numid=case catches its own site.
Generated by Claude Code
What this fixes
CVE-2026-90781 is a one-byte stack overrun in
__snd_ctl_ascii_elem_id_parse()(src/control/ctlparse.c). The function copies aname=value into a 64-bytebuf, and a name of 64 or more characters makes it write the closing'\0'one byte past the end. The NVD/CVE text says "alsa-lib through 1.2.16.1". 1.2.16.1 is what we ship, and it is still the latest release.alsa-project/alsa-lib@f84cd4c(2026-08-30), not yet in any release.gh api …/compare/f84cd4c...v1.2.16.1returnsbehind, so the fix is not in our tag.1e27d63e(2026-06-02), which fixes the same one-byte overrun on thenumid=branch of the same function.git merge-base --is-ancestor 1e27d63e v1.2.16.1is false, so f84cd4c alone would leave that site open. These two are the only commits touchingctlparse.csince the tag, and with both applied all three copy loops bound atsizeof(buf) - 1.1.2.16.1-2.Changes
CVE-2026-90781.patch(f84cd4c) andCVE-2026-90781-numid.patch(1e27d63e). Each is the upstream commit'sgit format-patch, unmodified. They touch different hunks and apply in either order.build.shapplies it withpatch -Np1underset -e, so a hunk that no longer applies fails the build instead of shipping an unpatched library. This follows the existingwgetandpythonpattern, and addspatchtobuild_deps.'\0'one byte out of bounds, so nothing observable changes and a plain behavioural test can't see it. The test therefore compilesctlparse.citself under-fsanitize=address, because the copy insidelibasound.sois not instrumented. It then parses 100-character quoted and unquotedname=values and a 100-digitnumid=.-22) after an in-bounds copy.AddressSanitizer: stack-buffer-overflow … ctlparse.c:239 in __snd_ctl_ascii_elem_id_parse.AddressSanitizer: stack-buffer-overflow … ctlparse.c:182 in __snd_ctl_ascii_elem_id_parse, thenumid=branch.source_provenance = GithubRepo alsa-project/alsa-lib. alsa-lib had no provenance, so the advisory pipeline never asked about it, and it has zeroadvisory_lifecyclerows. This advisory already sits in prodadvisoriesunderpkg:github/alsa-project/alsa-lib, the purl this provenance produces. github.com/alsa-project is upstream's own home, not a mirror. Thealsa-project.orgtarball URL in the comment is the release download.Verification
All of this ran in a
min sessionwith thepkgbuildloadout, on arm64:min package build --rebuild --verbose alsa-lib:patching file src/control/ctlparse.c(twice),make checkpasses, the regression test passes,build finished.min check --packages alsa-lib: every check passes, including the build-dependent enumerate-bins, missing-runtime_deps and standalone tests.Notes for the reviewer
fixed: 1.2.16.1to the release commit. The scanner does not see carried patches, so the finding stays until the next alsa-lib release, or until someone files a VEXnot_affected / inline_mitigations_already_existforpkg:github/alsa-project/alsa-lib.update: on the first upstream release that containsf84cd4c/1e27d63e, each patch reverse-applies and is removed automatically, together with thisbuild.nclentry and thebuild.shline.openjdk-9 … openjdk-25boot-JDK ladder,icedtea-7/8,jdk-21/25/27, andchromium-bin/chromium-headless-shell-bin. The ladder rebuilds serially, so expect a long CI run.Refs gominimal/pkgmgr-rs#848
🤖 Generated with Claude Code