Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Olivain via buildroot <buildroot@buildroot.org>
To: Peter Korsgaard <peter@korsgaard.com>
Cc: buildroot@buildroot.org, Thomas Perale <thomas.perale@mind.be>,
	Christian Stewart <christian@aperture.us>
Subject: Re: [Buildroot] [PATCH] package/go: security bump to version 1.26.6
Date: Mon, 17 Aug 2026 19:50:51 +0200	[thread overview]
Message-ID: <aca3155e78202eda49481db4b7722667@free.fr> (raw)
In-Reply-To: <20260817153641.736799-1-peter@korsgaard.com>

On 17/08/2026 17:36, Peter Korsgaard wrote:
> Fixes the following security issues:
> 
>  - x/mod/sumdb/tlog: fix transparency log tile verification bypass
> 
>    A malicious GOPROXY was previously capable of forging up to two 
> sumdb
>    tiles that allow for a requested module to bypass the GOSUMDB check 
> and
>    persist attacker-controlled module content to a local Go module 
> cache.
> 
>    This attack allows for a malicious GOPROXY to serve malicious module
>    content that cannot be detected by evaluating the transparency log.
> 
>    All tiles are now correctly verified against their parents.
> 
>    In order to determine if you have been affected:
> 
>    rm -r go.sum go.work.sum vendor/ && go mod tidy
> 
>    Thanks to Filippo Valsorda (Geomys) for reporting this issue.
> 
>    This is CVE-2026-56865 and Go issue https://go.dev/issue/80744.
> 
>  - x/mod/sumdb: ignore unrelated, unauthenticated hashes in Lookup
> 
>    A malicious GOSUMDB was capable of serving arbitrary module content 
> not
>    contained within the transparency log.
> 
>    This attack allows for a coordinating GOPROXY and GOSUMDB to serve a
>    client malicious module content that cannot be detected by 
> evaluating
>    the transparency log.
> 
>    In order to determine if you have been affected:
> 
>    rm -r go.sum go.work.sum vendor/ && go mod tidy
> 
>    Thanks to mundur for reporting this issue.
> 
>    This is CVE-2026-56864 and Go issue https://go.dev/issue/80745.
> 
>  - encoding/xml: add recursion depth guard during decode
> 
>    Previously, DecodeElement would reset the depth counter causing it 
> to
>    never fire; this could lead to stack exhaustion.
> 
>    This is CVE-2026-56859 and Go issue https://go.dev/issue/80481.
> 
>  - net/http: apply ReadHeaderTimeout when doing unencrypted HTTP/2 
> check
> 
>    When a server is configured to support unencrypted HTTP/2, it reads 
> a few
>    bytes from each new connection to see if they contain the HTTP/2 
> client
>    preface.  Previously, this was being done with no timeout applied.
>    ReadHeaderTimeout is now applied for this.
> 
>    This is CVE-2026-56853 and Go issue https://go.dev/issue/80205.
> 
>  - net/url: avoid quadratic complexity in resolvePath
> 
>    Previously, resolving relative paths containing parent directory 
> (..)
>    segments performed string conversions and buffer rewrites on each 
> step,
>    resulting in quadratic time complexity and high memory allocation
>    overhead.
> 
>    Now, path resolution operates on a byte buffer using index-based
>    backtracking for ..  segments, eliminating the quadratic time 
> complexity
>    and significantly reducing memory allocations.
> 
>    This is CVE-2026-56860 and Go issue https://go.dev/issue/80494.
> 
>  - golang.org/x/net/dns/dnsmessage: panic when parsing invalid SVCB 
> record
> 
>    Parsing an invalid SVCB or HTTPS RR can panic when the size of a
>    parameter value overflows the message buffer.
> 
>    Thanks to Mundur (https://github.com/M0nd0R) for reporting this 
> issue.
> 
>    This is CVE-2026-46600 and Go issue https://go.dev/issue/79795.
> 
>  - crypto/tls: limit handshake messages we are willing to accept 
> post-handshake
> 
>    Previously, we always counted handshake messages, such as KeyUpdate, 
> as
>    state-advancing, regardless of whether a handshake has been 
> completed or
>    not.  As a result, a malicious client can keep sending KeyUpdate 
> messages
>    to force the server to keep performing key derivation operations
>    indefinitely.
> 
>    Thanks to Qi Deng of Aurascape.ai for reporting this issue.
> 
>    This is CVE-2026-56862 and Go issue https://go.dev/issue/80528.
> 
>  - html/template: fix Javascript regexp context tracking
> 
>    Previously, pathological inputs could close an unescaped / early,
>    allowing for attack-controlled data to inject arbitrary content,
>    potentially leading to XSS.
> 
>    Thanks to Ali Sherif for reporting this issue.
> 
>    This is CVE-2026-56858 and Go issue https://go.dev/issue/80435.
> 
>  - x/net/idna: failure to reject ASCII-only Punycode-encoded labels
> 
>    The ToASCII and ToUnicode functions incorrectly accepted 
> Punycode-encoded
>    labels that decode to an ASCII-only label.  For example,
>    ToUnicode("xn--example-.com") incorrectly returned the name 
> "example.com"
>    rather than an error.
> 
>    The idna package implements the processing algorithm from UTS 46.  
> Older
>    versions of UTS 46 included a specification bug which permitted 
> multiple
>    ASCII labels to decode to the same Unicode label.  UTS 46 revision 
> 33
>    fixed the specification bug.  The idna package now implements the 
> updated
>    specification.
> 
>    This behavior can lead to privilege escalation in programs using the 
> idna
>    package.  For example, a program which performs privilege checks on 
> the
>    ASCII hostname may reject "example.com" but permit 
> "xn--example-.com".
>    If that program subsequently converts the ASCII hostname to Unicode, 
> it
>    will inadvertently permits access to the Unicode name "example.com".
> 
>    Thanks to KC1zs4 (https://github.com/KC1zs4) for reporting this 
> issue.
> 
>    This is CVE-2026-39821 and Go issue https://go.dev/issue/78760.
> 
>  - encoding/asn1: enforce maximum recursion depth
> 
>    Enforce a recursion limit in Unmarshal to prevent stack exhaustion 
> when
>    parsing deeply-nested, recursive structures.
> 
>    Thanks to Marwan Atia (marwansamir688@gmail.com) for reporting this 
> issue.
> 
>    This is CVE-2026-33818 and Go issue https://go.dev/issue/80405.
> 
> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

Applied to master, thanks.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

      reply	other threads:[~2026-08-17 17:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-17 15:36 [Buildroot] [PATCH] package/go: security bump to version 1.26.6 Peter Korsgaard
2026-08-17 17:50 ` Julien Olivain via buildroot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aca3155e78202eda49481db4b7722667@free.fr \
    --to=buildroot@buildroot.org \
    --cc=christian@aperture.us \
    --cc=ju.o@free.fr \
    --cc=peter@korsgaard.com \
    --cc=thomas.perale@mind.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox