x/text/unicode/norm: infinite loop on truncated/invalid UTF-8 input

[neild]

A norm.Iter can enter an infinite loop when handling input containing invalid UTF-8 bytes.

This is a PUBLIC track vulnerability and CVE-2026-56852.

[gopherbot]

Change https://go.dev/cl/794100 mentions this issue: unicode/norm: avoid infinite loop on invalid input

[dagood]

Will this be vendored into Go release branches?

(Someone asked the same question in #79795 and that seemed to drive some action that clearly indicates that there will be backports for that issue. 🙂 I'm asking this on others' behalf because CVE scanners point out CVE-2026-56852 in new builds of Go.)

[nicholashusin]

I'm asking this on others' behalf because CVE scanners point out GHSA-jpjm-c3r5-q96r in new builds of Go.

@dagood would you mind sharing more details about this? Specifically, what CVE scanners are being used, and is it just scanning the main Go repo?

From a quick test (my build and tests pass after deleting the vulnerable symbols and any code that depends on it), for this vulnerability, the vulnerable symbols is not actually reachable from the main Go repo despite being vendored in. In such cases, backports are not really needed.

[dagood]

Specifically, what CVE scanners are being used, and is it just scanning the main Go repo?

From a quick test (my build and tests pass after deleting the vulnerable symbols and any code that depends on it), for this vulnerability, the vulnerable symbols is not actually reachable from the main Go repo despite being vendored in.

Unfortunately, I don't know, but I do believe from past experience that it isn't smart about reachability. It just sees the module referenced in the Go toolset and stops there. (And this is bad--I agree with the points on e.g. https://words.filippo.io/dependabot/ about that.)

(Background: I maintain a fork of Go, and people sometimes come to me asking about specific CVEs. I don't have much say in what scanners they use and how they treat and investigate the results, and they might not even be familiar with Go.)

In such cases, backports are not really needed.

I agree, the trouble I'm having is that when I'm looking at an issue like this, it's not clear to me if the Go security team has truly evaluated this, or if (like what seems to have happened in #79795) the question is fresh.

In theory, I can investigate this myself (and if I know the stdlib is vulnerable, I would go through https://go.dev/doc/security/policy#flagging-existing-issues-as-security-related), but that's a pretty heavyweight process for N people to independently go through when reading this issue. I'd also prefer to be able to point at an official Go security team opinion when possible. 🙂

[nicholashusin]

That makes sense, thanks!

To give more context, in cases like #79795, the backport process are oftentimes only started nearer to a security release. The GitHub issue might have been closed, but we also still keep track of it separately internally to make sure that backports, if needed, are done.

Point taken on the external scanners and the ability to point at an official Go security team opinion. I'm not sure how far we should go trying to satisfy an overly eager scanner, but giving more clarity whether an issue not being backported is intentional or not sounds beneficial.

Perhaps we could consider always opening backport issues for all security issues, and marking them as "Won't fix" or so when they are not actually needed, to make things explicit? I'll bring this up with the security and release team.

[dagood]

Perhaps we could consider always opening backport issues for all security issues, and marking them as "Won't fix" or so when they are not actually needed, to make things explicit? I'll bring this up with the security and release team.

That sounds perfect to me, if possible! Thanks for the extra details and raising that possibility.