Repository navigation
fix(libslirp): upgrade to 4.9.7 to address CVEs - #19974
Kanishk Bansal (Kanishk-Bansal) wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
🟡 Changes recommended
The PR description lists CVE-2026-95508 as unaddressed despite the imported changelog listing a fix, so the CVE table and fixed-CVE count need reconciliation.
1 open issue
What changed in this PR
Upgrades Azure Linux’s libslirp from 4.9.1 to 4.9.7 using a pinned Fedora rawhide commit to incorporate upstream security fixes.
Changes:
- Moves
libslirpinto a dedicated component definition with an explicit upstream pin. - Refreshes the component lock and source checksum.
- Updates the rendered spec’s version, packaged license files, and upstream changelog.
| File | Description |
|---|---|
specs/l/libslirp/sources |
Updates the source archive and SHA512 checksum for 4.9.7. |
specs/l/libslirp/libslirp.spec |
Updates the version, includes LICENSE, and imports upstream changelog entries. |
locks/libslirp.lock |
Records the new upstream commit and refreshed fingerprints. |
base/comps/libslirp/libslirp.comp.toml |
Adds the dedicated definition pinned to Fedora rawhide. |
base/comps/components.toml |
Removes the inline entry replaced by the dedicated definition. |
Review effort: Balanced
|
|
||
| * Tue Sep 22 2026 Marc-André Lureau <marcandre.lureau@redhat.com> - 4.9.5-1 | ||
| - new version, rhbz#2524215 | ||
| - Fix CVE-2026-95508: heap buffer overflow in DHCPv6/TFTP response builders on small interface MTU |
There was a problem hiding this comment.
Reconciled: the PR description now lists CVE-2026-95508 as addressed (fixed upstream in 4.9.6, included in 4.9.7), along with CVE-2026-120830, CVE-2026-120831 and CVE-2026-115449 — 5 CVEs in total, all claimed against this PR in Astrolabe. The commit message has been updated to match.
|
/azp run |
|
Azure Pipelines: 2 pipeline(s) were filtered out due to trigger conditions. |
Kanishk Bansal (Kanishk-Bansal)
added
security
CVE-fixed-by-upgrade
Elaheh Dehghani (ellie-di)
left a comment
Elaheh Dehghani (ellie-di)
left a comment
There was a problem hiding this comment.
please update the commit message to list all the fixed CVEs.
Bump the Fedora rawhide dist-git pin to libslirp-4.9.7: https://src.fedoraproject.org/rpms/libslirp/c/842747952c1b96eb5376c5d44f52728f9fd8b5f8 Addresses 5 CVE(s): CVE-2026-115449, CVE-2026-120830, CVE-2026-120831, CVE-2026-9539, CVE-2026-95508 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Elaheh Dehghani (@ellie-di) Thanks — updated the commit message to list all 5 CVEs addressed by this PR (CVE-2026-115449, CVE-2026-120830, CVE-2026-120831, CVE-2026-9539, CVE-2026-95508), matching the PR description and Astrolabe. Only the commit message changed; the rendered spec, sources and lock are identical to the previous push. |
453136c to
b9b0541
Compare
|
/azp run |
|
Azure Pipelines: 2 pipeline(s) were filtered out due to trigger conditions. |
|
|
||
| Name: libslirp | ||
| Version: 4.9.1 | ||
| Version: 4.9.7 |
There was a problem hiding this comment.
issue (blocking): There looks to be a possible upstream issue. I'm getting a reproducer built and will share that shortly, but sharing the raw copilot review information below
====
issue (blocking): Preserve complete TFTP transfers when negotiating larger blocks
The selected 4.9.7 source introduces a TFTP regression compared with 4.9.1. With TFTP enabled, the default IPv4 MTU of 1500, a file larger than one block, and a valid blksize=8192 request, 4.9.7 advertises 8192 in OACK but sends only 1468 data bytes and terminates the session. A client interprets a DATA packet shorter than the negotiated block size as EOF, so a transfer can finish with a truncated file.
The mismatch is between tftp_handle_rrq() accepting the requested size and tftp_send_next_block() independently limiting the read to the MTU, then treating the short read as EOF. In 4.9.1, negotiation instead caps the advertised size at 1428, and the sender uses that same size.
I reproduced the difference using the actual upstream negotiation assignment and sender functions in an isolated C harness with the same 20-KB file-read model:
4.9.1: requested=8192 negotiated=1428 first_data=1428 active=1
4.9.7: requested=8192 negotiated=8192 first_data=1468 active=0
The 4.9.7 source used for that reproduction is byte-identical to src/tftp.c in the archive whose SHA512 matches this PR's sources entry. This is a function-level reproduction with mocked allocation, file reads, and UDP output, not an end-to-end guest transfer.
Please backport a fix that caps the negotiated block size to the usable MTU payload before sending OACK, or select an upstream release containing an equivalent fix. Keep the existing bounds checks; reverting the security hardening is not the fix. Add the patch through the component's canonical configuration, regenerate the spec/lock/source artifacts as applicable, and verify a multi-block transfer's final length and checksum.
Summary
Upgrade
libslirpfrom 4.9.1 → 4.9.7 by bumping the Fedora rawhide dist-git pin to842747952c1b.CVEs addressed (5)
CVEs not addressed by this upgrade (0)
None — all open Astrolabe CVEs for this package are addressed.
Changes
base/comps/libslirp/libslirp.comp.toml: pinupstream-commit = 842747952c1b…(Fedora rawhide)locks/libslirp.lock: refreshed viaazldev comp update -p libslirpspecs/l/libslirp/: re-rendered (Version 4.9.1 → 4.9.7, Release 5%{?dist} → 5%{?dist})Testing
azldev comp build -p libslirp(x86_64): success (2 RPMs)ldd: nonot found)azldev comp render/comp updateidempotent on the committed state; commit message passes commitizenNotes for reviewers