Repository navigation
giflib: 5.2.2 -> 6.1.3 + CVE-2026-26740 backport - #914
Conversation
6.1.2 fixes CVE-2026-23868 (GifMakeSavedImage double-free). 6.1.3 still carries CVE-2026-26740 (EGifGCBToSavedExtension heap OOB write); the fix (upstream 0616050) is on giflib master but unreleased, so it rides as a fail-closed patch. CVE-2024-45993 is in gif2rgb, which this recipe never built; 6.1.1 also moved gif2rgb to obsolete. soname stays libgif.so.7. The only API change is EGifSpew's new ErrorCode param; OpenJDK's splashscreen only decodes and already takes the GIFLIB_MAJOR > 5 branch in every rung (9..25). Tests: an OpenJDK-style in-memory decode with a version pin, and a CVE-2026-26740 regression that fails without the patch. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation |
|---|---|---|
| Description Check | Check skipped - CodeRabbit’s high-level summary is enabled. | |
| Title check | The title clearly and concisely identifies the primary changes: the giflib version update and the CVE-2026-26740 backport. | |
| Docstring Coverage | No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 1… | |
| Linked Issues check | Check skipped because no linked issues were found for this pull request. | |
| Out of Scope Changes check | Check skipped because no linked issues were found for this pull request. |
Full details: Docstring Coverage
-
Explanation
No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 1 files. (2 skipped: 2 unsupported.)
✨ Finishing Touches
-
📝 Generate docstrings
-
- Commit to this branch
- Create a new PR
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
There was a problem hiding this comment.
LGTM.
- The sha256 matches the SourceForge 6.1.3 tarball.
- The hunk matches upstream
061605081115and applies to 6.1.3. - The soname stays
libgif.so.7, so the globs hold. - The only dependents (openjdk-9…25) are decoders, so the
EGifSpew()ABI change doesn't affect them.
Nit, build.ncl:84: the version guard GIFLIB_MAJOR == 6 && (GIFLIB_MINOR > 1 || GIFLIB_RELEASE >= 2) also accepts 6.0.2–6.0.x. It should be (GIFLIB_MINOR > 1 || (GIFLIB_MINOR == 1 && GIFLIB_RELEASE >= 2)). It doesn't affect this build.
Generated by Claude Code
Bumps
giflib5.2.2 → 6.1.3 and backports the unreleased upstream fix for CVE-2026-26740. Found by minimal-supply-chain#519.pkgmgr vulns --package giflibshowed three open advisories against 5.2.2.CVEs
GifMakeSavedImage(libgif)EGifGCBToSavedExtensionwrites 4 bytes into an existing GCE block without checkingByteCount(libgif)0616050(giflib master, 2026-06-01), which hasn't been released yet. It ships as0001-CVE-2026-26740-egif-gcb-bounds-check.patch(git format-patchof that commit), applied withpatch -Np1underset -exso a failed hunk fails the build. Remove it once a giflib release includes it.gif2rgbCLI toollibgif.soandlibgif.a, never the utilities. NVD's CPE pins exactly 5.2.2, so the bump clears the scanner row. Upstream also movedgif2rgbto "obsolete" in 6.1.1.NVD's CPE for CVE-2026-26740 names only 5.2.2. Without the patch, the scanner would report 6.1.3 as clean while the library was still vulnerable.
Bump vs backport
libgif.so.7(LIBMAJOR=7in the 6.1.3 Makefile,-Wl,-soname -Wl,libgif.so.7in the build log). Theoutputsglobs are unchanged.EGifSpew()gained anE_GIF_ERR_*codes were renumbered (201+).gif_lib.hhas no other changes.libsplashscreen/splashscreen_gif.c) only decodes, usingDGifOpen,DGifSlurpandDGifCloseFile. It already handles major version 6 through#if GIFLIB_MAJOR > 5 || (...), which selects the two-argumentDGifCloseFile. I checked this at jdk-9+181, jdk-10+46, jdk-12+33 and jdk25u.Consumer impact
The importers of
../giflib/build.nclareopenjdk-9throughopenjdk-25, all built with--with-giflib=system.icedtea-7andicedtea-8pass--disable-system-gifand don't import giflib. This change rebuilds every openjdk rung (9..25).Tests
decode_like_openjdk: decodes a 1x1 GIF89a from memory the way OpenJDK does (DGifOpenwith a read callback,DGifSlurp,DGifSavedExtensionToGCB, two-argumentDGifCloseFile). It also asserts at compile time that the header is ≥ 6.1.2, the first release with the CVE-2026-23868 fix.gcb_to_short_extension_rejected: regression test for CVE-2026-26740. It gives a saved image a 2-byte GCE block and requiresEGifGCBToSavedExtensionto returnGIF_ERRORand leave the block untouched. Negative control: I rebuilt with thepatchline disabled. This test failed anddecode_like_openjdkstill passed.Verification
min package build --rebuild --verbose giflib(arm64 min session): built, patch applied (patching file egif_lib.c).min check --packages giflib: all checks pass, including standalone tests.min package build --rebuild --verbose openjdk-9(cheapest consumer: boots from the cached icedtea-8, which does not import giflib) +min check --packages openjdk-9: build finished, all checks Pass. The session log was nearly silent, so the authoritative consumer evidence is this PR's CI build of the openjdk rungs.Notes
gs://minimal-staging-archives/giflib-6.1.3.tar.gz. It is the upstream SourceForge tarball, and its sha256b65b66b9…ab0ematches both the upstream download and the copy in the mirror.4a731ea(integer overflow and type fixes) and8abe475(Simplify GHC packaging by extracting bootstrap and build tools #203GifUnionColorMapNULL dereference). I didn't backport them, to keep this change limited to the CVEs.🤖 Generated with Claude Code
Summary by CodeRabbit
Bug Fixes
Updates