Recent giflib vulnerability and fix in giflib 6.3.1

Jim L.

Jim L.

The Sourceforge project for giflib has a commit tag 6.1.3 which includes a commit referencing and fixing CVE-2026-26740, with these lines at lines 693-695 of egif_lib.c introduced by commit [061605]:

Code: 
693            if (ep->ByteCount < 4) {
694                return GIF_ERROR;
695            }

However, the FreeBSD vulnerability entry says that giflib versions <= 6.1.3 remain vulnerable to CVE-2026-26740.
Is this a mistake in vuln.xml?

Code: 
  <vuln vid="dd6096e6-8555-11f1-b4c7-00a0980083d7">
    <topic>giflib -- Buffer Overflow vulnerability</topic>
    <affects>
    <package>
        <name>giflib</name>
        <range><le>6.1.3</le></range>
    </package>
    </affects>
    <description>
        <body xmlns="http://www.w3.org/1999/xhtml">
        <p>https://github.com/zakkanijia/POC/blob/main/giflib/giftool/giflib_giftool_gce_len_heap_oobwrite_disclosure.md repo
rts:</p>
        <blockquote cite="https://github.com/zakkanijia/POC/blob/main/giflib/giftool/giflib_giftool_gce_len_heap_oobwrite_dis
closure.md">
          <p>Buffer Overflow vulnerability in giflib v.5.2.2 allows a remote
          attacker to cause a denial of service via the EGifGCBToExtension
          overwriting an existing Graphic Control Extension block without
          validating its allocated size.</p>
        </blockquote>
        </body>
    </description>
    <references>
      <cvename>CVE-2026-26740</cvename>
      <url>https://cveawg.mitre.org/api/cve/CVE-2026-26740</url>
    </references>
    <dates>
      <discovery>2026-03-18</discovery>
      <entry>2026-07-21</entry>
    </dates>
  </vuln>
 
Am I right to infer then, that the port got updated to 6.1.3 before the commit that added those three lines?

If so, can @desktop please patch graphics/giflib/Makefile?

Code: 
--- Makefile.old     2026-07-24 13:23:30.354623000 -0700
+++ Makefile    2026-07-24 14:13:44.296529000 -0700
@@ -1,5 +1,6 @@
 PORTNAME=      giflib
 PORTVERSION=   6.1.3
+PORTREVISION=  1
 CATEGORIES=    graphics
 MASTER_SITES=  SF/${PORTNAME}/giflib-6.x

distinfo is already correct for the non-vulnerable source code, so no changes needed:

Code: 
poutine : 14:21:10 /usr/ports/graphics/giflib# cat distinfo  
TIMESTAMP = 1784658362
SHA256 (giflib-6.1.3.tar.gz) = b65b66b99f0424b93525f987386f22fc5efb9da2bfc92ad4a532249aaffbab0e
SIZE (giflib-6.1.3.tar.gz) = 470579
poutine : 14:21:18 /usr/ports/graphics/giflib# ls -l /usr/ports/distfiles/giflib-6.1.3.tar.gz; sha256 /usr/ports/distfiles/gi
flib-6.1.3.tar.gz
-rw-r--r--  1 root wheel 470579 Apr 12 10:17 /usr/ports/distfiles/giflib-6.1.3.tar.gz
SHA256 (/usr/ports/distfiles/giflib-6.1.3.tar.gz) = b65b66b99f0424b93525f987386f22fc5efb9da2bfc92ad4a532249aaffbab0e
poutine : 14:21:40 /usr/ports/graphics/giflib# make checksum
===>  License MIT accepted by the user
===>   giflib-6.1.3_1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by giflib-6.1.3_1 for building
=> SHA256 Checksum OK for giflib-6.1.3.tar.gz.

Adding the PORTREVISION will allow users to build the latest version without the false positive vulnerability report.

Thank you!

(link sent to desktop@)
 
Yes, you're correct, I neglected to pay attention to the source between "make extract" and "make patch". The distinfo points to the vulnerable code.

Taking a harder look at the Sourceforge commits, it looks like 6.1.3 was released in April, then fixed in June, with no change to the tag/version number. Is there no possibility of having 6.1.3 built from the FreeBSD port prior to June 10 (vulnerable), vs. having 6.1.3 built from ports post-June 10 (not vulnerable)? IANAE, but it still seems to me that bumping PORTREVISION would be wise, given that the Sourceforge project doesn't (seem to) have any version distinction between the vulnernable 6.1.3 and the fixed 6.1.3. I suppose the way to answer my own question would be to find when it was that the FreeBSD ports tree first received the 6.1.3 commit, and what bits were included in that.

Thanks for chiming in!
 
You must log in or register to reply here.
Back
Top