From patchwork Sat Oct 3 10:00:44 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Marko X-Patchwork-Id: 99922 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 038BACA5FE3 for ; Sat, 3 Oct 2026 10:01:25 +0000 (UTC) Received: from mta-64-228.siemens.flowmailer.net (mta-64-228.siemens.flowmailer.net [185.136.64.228]) by mx.groups.io with SMTP id smtpd.msgproc01-g2.2945.1791021684166147455 for ; Sat, 03 Oct 2026 03:01:24 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=peter.marko@siemens.com header.s=fm1 header.b=M+aU4l0U; spf=pass (domain: rts-flowmailer.siemens.com, ip: 185.136.64.228, mailfrom: fm-256628-202610031001218c3590776900020736-sdrnfo@rts-flowmailer.siemens.com) Received: by mta-64-228.siemens.flowmailer.net with ESMTPSA id 202610031001218c3590776900020736 for ; Sat, 03 Oct 2026 12:01:21 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=fm1; d=siemens.com; i=peter.marko@siemens.com; h=Date:From:Subject:To:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:Cc:References:In-Reply-To; bh=HrQCVk290MbCLl7xrBoC3qmw4iFAFxVaT+bir+XfLyA=; b=M+aU4l0UytcnjR42tvKcpY4U7V4VeUBHPaTNFXMzJsYJV19fTgzX3P1zaM3LJCnx0qWpBA 3qJW0dpd92ElvR1yMQCPFd3IZLHLEOeAHWvOeMDKSP4CAYJhH8ZbVqvsLJFpfeX9ppNEJMB0 2h24B1s2Gy8cqIA7A9jLWfWd6fgKST+gIJfuCYs24bP4qLpIRpjCzISHztCNSqWWhSglGMqL fTtWwfZzjFcugnbHrt63E2+A4agpZEelu3mpPBhSBFxWixNZN1eFjghT/ReqAIGeYBmJ9DKd iQ5tRPFRuxwO+7nhLVHd1On4Mnv1DCsSCpWXxeuaruRI7Ubn5erY8lFQ==; From: Peter Marko To: openembedded-core@lists.openembedded.org Cc: Peter Marko Subject: [scarthgap][PATCH 2/2] libpng: patch CVE-2026-46675 Date: Sat, 3 Oct 2026 12:00:44 +0200 Message-ID: <20261003100044.3979222-2-peter.marko@siemens.com> In-Reply-To: <20261003100044.3979222-1-peter.marko@siemens.com> References: <20261003100044.3979222-1-peter.marko@siemens.com> MIME-Version: 1.0 X-Flowmailer-Platform: Siemens Feedback-ID: 519:519-256628:519-21489:flowmailer List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Sat, 03 Oct 2026 10:01:24 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/247156 From: Peter Marko Pick patch per [1]. [1] https://security-tracker.debian.org/tracker/CVE-2026-46675 Signed-off-by: Peter Marko --- .../libpng/files/CVE-2026-46675.patch | 115 ++++++++++++++++++ .../libpng/libpng_1.6.42.bb | 1 + 2 files changed, 116 insertions(+) create mode 100644 meta/recipes-multimedia/libpng/files/CVE-2026-46675.patch diff --git a/meta/recipes-multimedia/libpng/files/CVE-2026-46675.patch b/meta/recipes-multimedia/libpng/files/CVE-2026-46675.patch new file mode 100644 index 00000000000..3af0251c553 --- /dev/null +++ b/meta/recipes-multimedia/libpng/files/CVE-2026-46675.patch @@ -0,0 +1,115 @@ +From aa77ef38c17ab2fc1b41bec09fb973c6a386641d Mon Sep 17 00:00:00 2001 +From: Cosmin Truta +Date: Wed, 23 Sep 2026 18:30:11 +0300 +Subject: [PATCH] fix: Clear stale zstream pointers when releasing the inflate + stream + +The zstream buffer pointers and counters are all cleared on acquisition +in `png_inflate_claim`, but only `next_in` and `avail_in` were cleared +on release in `png_read_finish_IDAT`, and none were cleared on release +in the chunk decompression paths. + +If `png_read_end` is called before row reading starts, the IDAT stream +is never claimed. Previously, a leftover non-zero `avail_in` caused the +refill in `png_read_IDAT_data` to be skipped, and inflation continued +through a stale `next_in` into an input buffer that may since have been +deallocated. + +Introduce the function `png_inflate_detach_buffers` to clear the +pointers and the counters of zstream input and output buffers on both +acquisition and release. Although clearing `next_out` and `avail_out` +is not currently necessary at any call site, it makes release mirror +acquisition at a negligible cost paid once for each zlib stream. + +This is a cherry-pick of commit 6c7783b151377f591c83955e23da50991ad1a600 +from branch 'libpng18'. + +Reported-by: Ze Sheng +Reported-by: JasonHonKL + +CVE: CVE-2026-46675 +Upstream-Status: Backport [https://github.com/pnggroup/libpng/commit/aa77ef38c17ab2fc1b41bec09fb973c6a386641d] +Signed-off-by: Peter Marko +--- + pngrutil.c | 33 +++++++++++++++++++-------------- + 1 file changed, 19 insertions(+), 14 deletions(-) + +diff --git a/pngrutil.c b/pngrutil.c +index 551395168..482f0ae8d 100644 +--- a/pngrutil.c ++++ b/pngrutil.c +@@ -332,6 +332,18 @@ png_read_buffer(png_structrp png_ptr, png_alloc_size_t new_size, int warn) + } + #endif /* READ_iCCP|iTXt|pCAL|sCAL|sPLT|tEXt|zTXt|SEQUENTIAL_READ */ + ++/* Detach the zstream from the input and output buffers left by ++ * the current or a previous owner, and possibly deallocated since. ++ */ ++static void ++png_inflate_detach_buffers(png_structrp png_ptr) ++{ ++ png_ptr->zstream.next_in = NULL; ++ png_ptr->zstream.avail_in = 0; ++ png_ptr->zstream.next_out = NULL; ++ png_ptr->zstream.avail_out = 0; ++} ++ + /* png_inflate_claim: claim the zstream for some nefarious purpose that involves + * decompression. Returns Z_OK on success, else a zlib error code. It checks + * the owner but, in final release builds, just issues a warning if some other +@@ -392,13 +404,7 @@ png_inflate_claim(png_structrp png_ptr, png_uint_32 owner) + + #endif /* ZLIB_VERNUM >= 0x1240 */ + +- /* Set this for safety, just in case the previous owner left pointers to +- * memory allocations. +- */ +- png_ptr->zstream.next_in = NULL; +- png_ptr->zstream.avail_in = 0; +- png_ptr->zstream.next_out = NULL; +- png_ptr->zstream.avail_out = 0; ++ png_inflate_detach_buffers(png_ptr); + + if ((png_ptr->flags & PNG_FLAG_ZSTREAM_INITIALIZED) != 0) + { +@@ -744,7 +750,8 @@ png_decompress_chunk(png_structrp png_ptr, + else if (ret == Z_OK) + ret = PNG_UNEXPECTED_ZLIB_RETURN; + +- /* Release the claimed stream */ ++ /* Release the claimed stream. */ ++ png_inflate_detach_buffers(png_ptr); + png_ptr->zowner = 0; + } + +@@ -1569,6 +1576,7 @@ png_handle_iCCP(png_structrp png_ptr, png_inforp info_ptr, png_uint_32 length) + + if (errmsg == NULL) + { ++ png_inflate_detach_buffers(png_ptr); + png_ptr->zowner = 0; + return; + } +@@ -1595,7 +1603,8 @@ png_handle_iCCP(png_structrp png_ptr, png_inforp info_ptr, png_uint_32 length) + else /* profile truncated */ + errmsg = png_ptr->zstream.msg; + +- /* Release the stream */ ++ /* Release the claimed stream. */ ++ png_inflate_detach_buffers(png_ptr); + png_ptr->zowner = 0; + } + +@@ -4294,11 +4303,7 @@ png_read_finish_IDAT(png_structrp png_ptr) + */ + if (png_ptr->zowner == png_IDAT) + { +- /* Always do this; the pointers otherwise point into the read buffer. */ +- png_ptr->zstream.next_in = NULL; +- png_ptr->zstream.avail_in = 0; +- +- /* Now we no longer own the zstream. */ ++ png_inflate_detach_buffers(png_ptr); + png_ptr->zowner = 0; + + /* The slightly weird semantics of the sequential IDAT reading is that we diff --git a/meta/recipes-multimedia/libpng/libpng_1.6.42.bb b/meta/recipes-multimedia/libpng/libpng_1.6.42.bb index f375aa5f4e9..8e7f9d8f8ec 100644 --- a/meta/recipes-multimedia/libpng/libpng_1.6.42.bb +++ b/meta/recipes-multimedia/libpng/libpng_1.6.42.bb @@ -32,6 +32,7 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/project/${BPN}/${BPN}${LIBV}/${PV}/${BP}.tar.xz file://CVE-2026-34757_p1.patch \ file://CVE-2026-34757_p2.patch \ file://CVE-2026-33416-05.patch \ + file://CVE-2026-46675.patch \ " SRC_URI[sha256sum] = "c919dbc11f4c03b05aba3f8884d8eb7adfe3572ad228af972bb60057bdb48450"