Toolchain directive in go.mod not being considered

[mattjohnsonpint]

Consider a project with a go.mod file as follows:

module example

go 1.23.5

toolchain go1.23.6

According to the docs for Go Toolchains:

Starting in Go 1.21, the Go distribution consists of a go command and a bundled Go toolchain, which is the standard library as well as the compiler, assembler, and other tools.

Since the standard library is part of the toolchain, then as long as Go 1.23.6 is installed, Go will use stdlib from Go 1.23.6 with this configuration.

However, OSV-Scanner reports:

Timing sidechannel for P-256 on ppc64le in crypto/internal/nistec. Current version of 'stdlib' is vulnerable: 1.23.5. osv-scanner/CVE-2025-22866

... which was one of the issues fixed in Go 1.23.6.

I conclude that the toolchain directive is not being honored. Is that correct?

[mattjohnsonpint]

That output was using osv-scanner via a Trunk plugin. Here's the same using osv-scanner 1.9.2 directly:

╭──────────────────────────────┬──────┬───────────┬─────────┬─────────┬────────╮
│ OSV URL                      │ CVSS │ ECOSYSTEM │ PACKAGE │ VERSION │ SOURCE │
├──────────────────────────────┼──────┼───────────┼─────────┼─────────┼────────┤
│ Uncalled vulnerabilities     │      │           │         │         │        │
├──────────────────────────────┼──────┼───────────┼─────────┼─────────┼────────┤
│ https://osv.dev/GO-2025-3447 │      │ Go        │ stdlib  │ 1.23.5  │ go.mod │
╰──────────────────────────────┴──────┴───────────┴─────────┴─────────┴────────╯

Full output with osv-scanner scan --json .:

{
  "results": [
    {
      "source": {
        "path": "/Users/matt/temp/example/go.mod",
        "type": "lockfile"
      },
      "packages": [
        {
          "package": {
            "name": "stdlib",
            "version": "1.23.5",
            "ecosystem": "Go"
          },
          "vulnerabilities": [
            {
              "modified": "2025-02-08T08:11:54Z",
              "published": "2025-02-06T16:38:14Z",
              "schema_version": "1.6.0",
              "id": "GO-2025-3447",
              "aliases": [
                "BIT-golang-2025-22866",
                "CVE-2025-22866"
              ],
              "summary": "Timing sidechannel for P-256 on ppc64le in crypto/internal/nistec",
              "details": "Due to the usage of a variable time instruction in the assembly implementation of an internal function, a small number of bits of secret scalars are leaked on the ppc64le architecture. Due to the way this function is used, we do not believe this leakage is enough to allow recovery of the private key when P-256 is used in any well known protocols.",
              "affected": [
                {
                  "package": {
                    "ecosystem": "Go",
                    "name": "stdlib",
                    "purl": "pkg:golang/stdlib"
                  },
                  "ranges": [
                    {
                      "type": "SEMVER",
                      "events": [
                        {
                          "introduced": "0"
                        },
                        {
                          "fixed": "1.22.12"
                        },
                        {
                          "introduced": "1.23.0-0"
                        },
                        {
                          "fixed": "1.23.6"
                        },
                        {
                          "introduced": "1.24.0-0"
                        },
                        {
                          "fixed": "1.24.0-rc.3"
                        }
                      ]
                    }
                  ],
                  "database_specific": {
                    "source": "https://vuln.go.dev/ID/GO-2025-3447.json"
                  },
                  "ecosystem_specific": {
                    "imports": [
                      {
                        "goarch": [
                          "ppc64le"
                        ],
                        "path": "crypto/internal/nistec",
                        "symbols": [
                          "P256Point.ScalarBaseMult",
                          "P256Point.ScalarMult",
                          "P256Point.SetBytes",
                          "p256NegCond"
                        ]
                      }
                    ]
                  }
                }
              ],
              "references": [
                {
                  "type": "FIX",
                  "url": "https://go.dev/cl/643735"
                },
                {
                  "type": "REPORT",
                  "url": "https://go.dev/issue/71383"
                },
                {
                  "type": "WEB",
                  "url": "https://groups.google.com/g/golang-announce/c/xU1ZCHUZw3k"
                }
              ],
              "database_specific": {
                "review_status": "REVIEWED",
                "url": "https://pkg.go.dev/vuln/GO-2025-3447"
              }
            }
          ],
          "groups": [
            {
              "ids": [
                "GO-2025-3447"
              ],
              "aliases": [
                "BIT-golang-2025-22866",
                "CVE-2025-22866",
                "GO-2025-3447"
              ],
              "experimentalAnalysis": {
                "GO-2025-3447": {
                  "called": false,
                  "unimportant": false
                }
              },
              "max_severity": ""
            }
          ]
        }
      ]
    }
  ],
  "experimental_config": {
    "licenses": {
      "summary": false,
      "allowlist": null
    }
  }
}

[mattjohnsonpint]

Aside - since the vuln is ecosystem_specific for ppc64le is there a convenient way to indicate that I don't target that platform, to avoid raising this at all?

[another-rex]

@G-Rath When you have time can you take a look at this issue? It seems like we just need to add support for the toolchain directive in osv-scalibr gomod extractor if it exists, and put it as a higher priority than the go directive.

[another-rex]

Aside - since the vuln is ecosystem_specific for ppc64le is there a convenient way to indicate that I don't target that platform, to avoid raising this at all?

We do ignore it by putting it under uncalled, and return with a 0 exit code if the only vulns that are there are uncalled.

I can see benefit of having a osv-scanner config setting to set what platform you are targeting to completely suppress this issue though, I'll make a new issue to track this feature request.

[G-Rath]

@another-rex no problem - I've just got a question on how we handle the difference between toolchains and concrete versions, and then it should be good to go

[mattjohnsonpint]

TBH, I'm not sure I fully understand all the implications of the toolchain directive, and I've read all the docs I can find on the subject.

It seems there are different concerns depending on whether one is making a library package, an executable package, or a unit test though they all share the same go.mod file.

For example, if I am writing a library, then the go directive in my own go.mod file is really the chief concern, but it only controls the API surface I can target. The toolchain directive of the consuming application's go.mod file is the one that would control the implementation version, which may or may not be subject to a vulnerability. My own library's toolchain directive would essentially be ignored, except for when running tests.

[another-rex]

From what I understand, since the person doing the scanning is likely to be the person building the application, we want to report the vulnerabilities they will have, therefore we should always take the toolchain as priority.

If you are distributing a library, it's not up to you to determine what stdlib your consumers will be using, so we probably shouldn't be reporting any vulnerabilities there (though we still do right now, since we don't know whether you are distributing a binary or library), but either way I don't think it matters as much, so we still can prioritise toolchain.