Update to Go 1.26.6 - #176
Merged
Merged
Conversation
…encrypted 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. This read was being done with no timeout applied. Apply the header timeout (since this is essentially reading the first headers from the connection). Hoist the header timeout into the server serve loop so we can use a single timeout to cover both the HTTP/2 preface and the first HTTP/1 headers. Thanks to Vsevolod Naumov and Ainar Garipov from AdGuard for reporting this issue. For golang#80205 Fixes golang#80224 For CVE-2026-56853 Change-Id: I4bbb917e11ccb9616594379ef556cee66a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/797520 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Nicholas Husin <nsh@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/797940 Reviewed-by: David Chase <drchase@google.com>
Pulls in a change to x/net/idna to reject all-ASCII xn-- labels. For golang#78760 Fixes golang#80298 Fixes CVE-2026-39821 Change-Id: I812f7167fe5a084dc2753b60347965946a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/799120 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
…from a directory on NetBSD read() on a directory file seems like it should produce an error, just like every other Unix, but golang#80322 indicates that it doesn't seem to. Just check that we're consistent with the non-Root case. For golang#80322 Fixes golang#80367 Change-Id: I499f9b0e2bac8e87647c83c5098db9cf6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/799080 Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Benny Siegert <bsiegert@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/799583 Reviewed-by: David Chase <drchase@google.com>
…ed by (*sigctxt).pushCall On arm64, the contents of R30 are saved in this 16-byte frame (when doing async preemption). But we don't scan that little frame. So any pointer that was in R30 will not get scanned. So the object it points to may get collected prematurely. Fixes golang#80394 The test here is pretty quick (~1/3 sec) and fails ~50% of the time. Change-Id: I46a7a6a25fabeb4f15dca96ee6fdd5e99d4c6323 Reviewed-on: https://go-review.googlesource.com/c/go/+/797521 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Keith Randall <khr@golang.org> (cherry picked from commit a129840) Reviewed-on: https://go-review.googlesource.com/c/go/+/800360 Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
MkdirAll("dir/") should create "dir", not return an error.
For golang#80308
Fixes golang#80365
Change-Id: I75458c30b6cb94be3a3d368f6024caef6a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/799064
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Nicholas Husin <nsh@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/799581
Reviewed-by: David Chase <drchase@google.com>
…an 9
CL 797880 changed Root to handle trailing slashes in
paths and added TestRootConsistencyRemoveAll.
However, this test is failing on Plan 9 because the "noat"
implementation of RemoveAll disagrees with Root.RemoveAll
when a path ends in a slash and its target is not a
directory. Root.RemoveAll strips the trailing slash and
removes the file, while os.RemoveAll leaves the slash in
place. On Plan 9, Remove and Lstat then fail on the
slash-terminated path, so os.RemoveAll returns an error
instead.
This change strips trailing slashes in the "noat"
implementation of RemoveAll, so RemoveAll("not_a_directory/")
removes the file and returns nil, and remains consistent
with the "at" implementation and Root.RemoveAll.
For golang#80319.
Fixes golang#80369
Change-Id: I5c47ccd239c629da78772f39a831cccf8c9d1500
Reviewed-on: https://go-review.googlesource.com/c/go/+/798721
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Richard Miller <millerresearch@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/799660
Reviewed-by: David Chase <drchase@google.com>
…inters in itabInit itabInit filled m.Fun by storing code pointers through an unsafe.Pointer slice, which makes the compiler emit a write barrier. On wasm a code PC is a function index shifted left 16 bits, a small value that can fall inside a live heap span, so the GC mistakes it for a bad heap pointer and crashes. Store through a uintptr slice instead so no write barrier is emitted, and mark itabInit //go:nowritebarrier so the same mistake fails to compile. Fixes golang#80499 Change-Id: If9532c01b66b8c4ceb47c932017569488b6143d5 GitHub-Last-Rev: 6e1374c GitHub-Pull-Request: golang#80487 Reviewed-on: https://go-review.googlesource.com/c/go/+/803460 Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/803900 Reviewed-by: Cherry Mui <cherryyz@google.com>
…ch_vm_region_trampoline This fixes a bug in mach_vm_region_trampoline. object_name is the 7th integer argument, so per the SysV AMD64 C ABI it is passed on the stack rather than in a register, but the trampoline only loaded it into R10 and never stored it, handing libc_mach_vm_region an uninitialized argument. I have no idea if this has negative impacts, but it would cause corrupted BPs to be loaded which needs to be fixed for the LEAVE commit comming later in that series. Fixes golang#80441 Updates golang#80439 Change-Id: I006f947c47ceda3c7b04e90ebccbee500493ec91 Reviewed-on: https://go-review.googlesource.com/c/go/+/801920 Auto-Submit: Jorropo <jorropo.pgm@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/804600 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
…s state-advancing 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. Fix the issue by making it so that handshake messages are regarded as state-advancing only prior to handshake completion. Thank you to Qi Deng of Aurascape.ai for reporting this issue. Updates golang#79866 Updates golang#80528 Fixes golang#80531 Fixes CVE-2026-56862 Change-Id: I37d27fd5f16227a9dde5f29bb5ae6c436a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/804261 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Neal Patel <nealpatel@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Neal Patel <neal@golang.org> (cherry picked from commit 2742057) Reviewed-on: https://go-review.googlesource.com/c/go/+/806980 Reviewed-by: Nicholas Husin <husin@google.com>
…vars in dead code DWARF generation's createConservativeVar asserts that every variable marked ir.EscHeap has a non-nil Heapaddr. This assumption only holds for reachable declarations. Escape analysis runs before SSA generation and is not reachability-aware, so it can mark a variable declared in dead code as heap-escaped. During SSA generation the ODCL for such a variable lands in an unreachable block, where stmt() returns early and never calls newHeapaddr. The variable is therefore left with Esc()==EscHeap but Heapaddr==nil, a legitimate state: the allocation was never generated, so there is no heap address to point at. Only build the heap-deref location list when Heapaddr is present, and otherwise emit a conservative variable with no location list, as was done before CL 684377. A reachable heap-escaped variable always gets a Heapaddr via newHeapaddr, so a nil Heapaddr uniquely identifies the dead-code case. Updates golang#80097. Fixes golang#80099. Change-Id: I91e475d0256c0f5e4d2dfabcacff92904469087a Reviewed-on: https://go-review.googlesource.com/c/go/+/792960 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/800181
Pull in the fix of x/net/dns/dnsmessage panic (golang#79795). Fixes golang#80609. Updates golang#79795. Change-Id: Ia3283185fd306bb2a4a811c6f65481b13832873d Reviewed-on: https://go-review.googlesource.com/c/go/+/808680 Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Nicholas Husin <nsh@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
…analysis We currently look for all uses of the address of a local, to find the maximum extent of the lifetime of a local. But the analysis doesn't handle the case where a use of the address is itself just a copy or pointer arithmetic, and the result of that use is then subsequently used outside the lifetime we currently compute. Maybe we could track down uses of uses, etc. But we do the safer thing here which is just to consider only uses that we know aren't propagating the address anywhere. Any other uses are considered bad and abort merging for the affected local. This is conservative but easy to reason about. In practice, these address copies don't come up all that often, as they are usually folded into load/store ops. The only typical use of an explicit address is initial zeroing (which this CL handles). Fixes golang#80478 Change-Id: Ia722a8314c1ace1b883ecedec1a3e06a2957a6b6 Reviewed-on: https://go-review.googlesource.com/c/go/+/796001 Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/803260
For Windows c-shared builds, peCreateExportFile writes a .def file containing a LIBRARY directive. When the output name has a trailing dot, as can happen for c-shared builds without an explicit -o, the directive was emitted as: LIBRARY mypackage. Some GNU ld versions reject that as invalid .def syntax. Emit the library name as a quoted .def string instead: LIBRARY "mypackage." This keeps ordinary output names working while allowing names with a trailing dot. Fixes golang#80131. Updates golang#78238. Change-Id: I45ddc09856016a0df233f73b8ec33ac7069a2aec Reviewed-on: https://go-review.googlesource.com/c/go/+/793280 Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 104f868) Reviewed-on: https://go-review.googlesource.com/c/go/+/808520 Reviewed-by: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
… disable EMS enforcement FIPS 140-3 mode requires EMS in TLS 1.2. Unfortunately, some deployments don't support EMS still, and have audit exemptions for it, but not for turning off FIPS 140-3 mode entirely. Add a GODEBUG to disable enforcement. There is no change of default behavior, the GODEBUG is off by default. Updates golang#80516 Fixes golang#80606 Change-Id: If93e2c1ea70dc5f34bcf7285549837576a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/804062 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Roland Shoemaker <roland@golang.org> (cherry picked from commit d2bb10c) Reviewed-on: https://go-review.googlesource.com/c/go/+/808040 Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Mark Freeman <markfreeman@google.com>
…I/LO On mips and mips64, multiply/divide results were tuple outputs in the special HI/LO registers, and regalloc kept live values homed there. Spilling such a value must route the data through REGTMP (there is no direct store from HI/LO). When the stack frame is too large for a 16-bit offset, the assembler also materializes the spill slot address in REGTMP: MOVV LO, R23 LUI R23, $1 DADDU R23, R23, SP SD R23, off(R23) clobbering the value and silently storing SP+0x10000 instead. Instead, make MULV/MULVU/DIVV/DIVVU (mips64) and MULT/MULTU/DIV/DIVU (mips) produce their results in two general registers, moving out of HI and LO as part of the op itself. Since register-register moves do not depend on REGTMP it can't get the dual use bug. Updates golang#80563 Fixes golang#80617 Change-Id: I2a0cb5ec7103ab2b0cbbeb67edd38ff5cb33bf77 Reviewed-on: https://go-review.googlesource.com/c/go/+/805420 Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Jorropo <jorropo.pgm@gmail.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/807180 Reviewed-by: Mark Freeman <markfreeman@google.com>
…injected calls This CL addresses two bugs related to moving goroutine stacks during injected function calls. The runtime injects calls during asynchronous preemption, when handling signals that get turned into panics (sigpanic), and for calls injected by a debugger. If a function triggers a sigpanic, and there is no way to resume execution in the function (such as through a deferred function), then that function's call frame is skipped during stack copying. The reasoning is that its locals, arguments, etc are dead. However, the call frame might contain a frame pointer. We can visit that frame pointer with the execution tracer or block/mutex profilers. If we visit that frame pointer after stack movement, it can point into the old stack. Following it will crash. This CL fixes this by adjusting the frame pointer if there is one. But it still skips the rest of the work, which is unnecessary. For arm64, there is an additonal frame pointer adjustment we're missing. Injected call frames are placed 16 bytes below the stack pointer at the point of call injection. This gap is needed both to avoid clobbering the frame pointer saved below the original function's call frame, and to have space to save the link register so it can be restored when the injected call returns. Normally when function A calls function B, the frame pointer saved below function A's frame is fixed when adjusting function B's frame. But because of the gap in the case of injection, the frame pointer saved by the original function isn't inside any call frame. We need to fix it when visiting the injected call frame. The regression test uses stackPoisonCopy so that the old stack is filled with garbage and frame pointer unwinding will reliably crash. Otherwise we'd only see a crash if something else happens to reuse the old stack space. Fixes golang#80715 Change-Id: I600d7942521e90852c67e379679b07e96a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/730200 Reviewed-by: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> (cherry picked from commit 40fd497) Reviewed-on: https://go-review.googlesource.com/c/go/+/810301 Reviewed-by: Carlos Amedee <carlos@golang.org>
…pointer offsets This was a latent bug revealed by CL 787720 which adds a bigger than 32bits slice pointer bump in it's test suite. Updates golang#80613 Fixes golang#80615 Change-Id: I47c49f6bd5ea83821de750b0c47b17a5e038d119 Reviewed-on: https://go-review.googlesource.com/c/go/+/807120 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Jorropo <jorropo.pgm@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Julian Zhu <jz531210@gmail.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/810021 Commit-Queue: Carlos Amedee <carlos@golang.org>
…r 64bits slicemasks Updates golang#79874 Fixes golang#79876 Change-Id: I155b6571db5b3c3537c549eadfe87a14b7d5836a Reviewed-on: https://go-review.googlesource.com/c/go/+/787720 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Jorropo <jorropo.pgm@gmail.com> Reviewed-by: Keith Randall <khr@google.com> (cherry picked from commit 395f4f5) Reviewed-on: https://go-review.googlesource.com/c/go/+/807240 Reviewed-by: Mark Freeman <markfreeman@google.com>
So we had an issue with some of the slices proofs. They ran in addLocalFacts which learned all values's proofs. The problem is that some proofs are only valid after executing certain values. This happens when a value adds relations in the factsTable about exclusively the value's arguments. But due to the descend / simplify separation simplify would run with all the proofs of the whole block. This CL include a huge amount of retabulation of code, all the meaningfull part is the changes to the prove function. Now we run: 1. flowLimit 2. constantFoldArguments 3. addValueFact 4. simplifyValue inside the same value loop. So thanks to toposorting, facts are learned in a valid execution order. And thanks to interleaving simplify for value v can only see v's facts. The tests from CL 807182 are included in this backport. Updates golang#80517 Fixes golang#80619 Change-Id: I36f5bce5102df55a9e5eca400dfd931c46323d71 Reviewed-on: https://go-review.googlesource.com/c/go/+/804220 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Jorropo <jorropo.pgm@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit a595f29) Reviewed-on: https://go-review.googlesource.com/c/go/+/807241 Reviewed-by: Mark Freeman <markfreeman@google.com>
…ion of unsigned values The riscv64 lowering rules remove sign extensions after 32-bit instructions, which architecturally sign-extend their result. However regalloc restores spilled values with an extension chosen from their type: unsigned 4-byte values are restored zero-extended, losing the sign extension the rules removed. Unlike what I've assumed in 80577 where I thought lower were correct and regalloc were wrongly ignoring lower's assumptions, it's much easier to fix the issue the other way around and make lower follows the existing assumptions (shared by arm64). Only remove the extension when a spill/restore preserves it, that is when the extended value's type is 8 bytes wide, or 4 bytes wide and signed. Updates golang#80577 Fixes golang#80579 Change-Id: I3cf5cff3f9026c6501f794114e6afd537506fa63 Reviewed-on: https://go-review.googlesource.com/c/go/+/806340 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Jorropo <jorropo.pgm@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/810460 Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
…ePath
Operate on a []byte with index-based backtracking instead of calling
dst.String() and dst.WriteString() per iteration.
goos: linux
goarch: amd64
pkg: net/url
cpu: AMD EPYC 7B13
│ b/gotip │ b/fixed │
│ sec/op │ sec/op vs base │
ResolvePath/Simple 123.85n ± 1% 94.56n ± 0% -23.65% (p=0.000 n=10)
ResolvePath/Deep 1.819µ ± 1% 1.611µ ± 1% -11.41% (p=0.000 n=10)
ResolvePath/Backtrack 6.439µ ± 2% 2.280µ ± 1% -64.59% (p=0.000 n=10)
geomean 1.132µ 702.9n -37.90%
│ b/gotip │ b/fixed │
│ B/op │ B/op vs base │
ResolvePath/Simple 16.000 ± 0% 4.000 ± 0% -75.00% (p=0.000 n=10)
ResolvePath/Deep 712.0 ± 0% 624.0 ± 0% -12.36% (p=0.000 n=10)
ResolvePath/Backtrack 9064.0 ± 0% 816.0 ± 0% -91.00% (p=0.000 n=10)
geomean 469.1 126.8 -72.98%
│ b/gotip │ b/fixed │
│ allocs/op │ allocs/op vs base │
ResolvePath/Simple 2.000 ± 0% 1.000 ± 0% -50.00% (p=0.000 n=10)
ResolvePath/Deep 7.000 ± 0% 3.000 ± 0% -57.14% (p=0.000 n=10)
ResolvePath/Backtrack 107.000 ± 0% 3.000 ± 0% -97.20% (p=0.000 n=10)
geomean 11.44 2.080 -81.82%
Updates golang#80494
Fixes golang#80630
Fixes CVE-2026-56860
Change-Id: I0aada41a0a10e2ce77c6476a65a49abc796dff3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/803681
Reviewed-by: Neal Patel <nealpatel@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit 594b58a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/806962
Reviewed-by: Carlos Amedee <carlos@golang.org>
This change prevents pathological inputs from closing an unescaped `/` early, allowing for attacker-controlled data to inject arbitrary unscaped content. Additionally, CL 532595 hints at the invariant in TestEscapeText potentially getting the update this change makes. For golang#80435 Fixes CVE-2026-56858 Change-Id: I502b8960249fa9a2827b44b64d081d224ac57cbc Reviewed-on: https://go-review.googlesource.com/c/go/+/807100 Reviewed-by: Neal Patel <nealpatel@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> (cherry picked from commit 0157ee9) Reviewed-on: https://go-review.googlesource.com/c/go/+/811020
…er).unmarshal (*Decoder).DecodeElement bypassed recursion depth guard by unilaterally passing the constant 0 to (*Decoder).unmarshal. Previously, unmarshal depth was tracked via a depth parameter passed down the call stack, which manual loops inside custom UnmarshalXML methods could bypass. This change simplifies depth tracking by maintaining a stack depth value that is adjusted as start elements are pushed / popped. This eliminates the need to reason about and synchronize two different values storing the unmarshal depth. Additionally, guarding (*Decoder).RawToken using parser stack state broke streaming decoders reading tokens within open XML elements. This change simplifies the guard by adding an explicit inUnmarshalXML flag. Thanks to Moran Omer (GitHub: moraneus) for reporting this issue. Updates golang#80481 Fixes golang#80628 Fixes CVE-2026-56859 Change-Id: I5e89ebe9101b03545520aba5ea99fbf15bdf0395 Reviewed-on: https://go-review.googlesource.com/c/go/+/803320 Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit ccb0514) Reviewed-on: https://go-review.googlesource.com/c/go/+/807540
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. Fixes CVE-2026-33818 Fixes golang#80405 Change-Id: Ic78d104432f8665a2949b95935fea23b5e35cff7 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/4780 Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5260 Reviewed-on: https://go-review.googlesource.com/c/go/+/814800 Auto-Submit: Gopher Robot <gobot@golang.org> TryBot-Bypass: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Mark Freeman <mark@golang.org>
Fixes golang#80745 Fixes CVE-2026-56864 Change-Id: Ia60dafca958d02a7ee0ec45d49e1db001c79d981 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5121 Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5201 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/814801 Reviewed-by: Mark Freeman <mark@golang.org> Auto-Submit: Gopher Robot <gobot@golang.org> TryBot-Bypass: Gopher Robot <gobot@golang.org>
Fixes golang#80744 Fixes CVE-2026-56865 Change-Id: I1e063053041c2d88b7801bfe09b6060f4def6afe Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5140 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5200 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/814802 Reviewed-by: Mark Freeman <mark@golang.org> Auto-Submit: Gopher Robot <gobot@golang.org> TryBot-Bypass: Gopher Robot <gobot@golang.org>
Change-Id: I04258bea694def9a16dd544fba28fea45eeadbbb Reviewed-on: https://go-review.googlesource.com/c/go/+/814840 TryBot-Bypass: Gopher Robot <gobot@golang.org> Reviewed-by: Mark Freeman <mark@golang.org> Auto-Submit: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
adrianosela
approved these changes
Aug 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
16 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release notes