[High] Patch kata-containers-cc for CVE-2026-84445 and CVE-2026-84304 by upgrading grpc vendor module

[Akhila Guruju (akhila-guruju)]

Summary

Patch kata-containers-cc for CVE-2026-84445 and CVE-2026-84304 by upgrading grpc vendor module

Problem: kata-containers-3.15.0.aks0 vendors google.golang.org/grpc v1.59.0 in src/runtime, which is affected by several xDS/HTTP-2 advisories.
Fix: Upgrade the vendored grpc module to v1.83.2 instead of backporting individual patches.

• Added generate_source_tarball.sh, which unpacks the upstream source, forces google.golang.org/grpc@v1.83.2, runs go mod tidy, and vendors the tree.
• %prep now swaps in the regenerated vendor tree before patching, keeping Source1 (cargo tarball) handling unchanged:

google.golang.org/grpc v1.59.0 → v1.83.2
google.golang.org/protobuf v1.35.2 → v1.36.11
golang.org/x/net v0.33.0 → v0.58.0
golang.org/x/text v0.21.0 → v0.41.0
golang.org/x/oauth2 v0.14.0 → v0.36.0
golang.org/x/sys v0.28.0 → v0.47.0
golang.org/x/sync v0.10.0 → v0.22.0
golang.org/x/mod v0.17.0 → v0.38.0
go.opentelemetry.io/otel v1.21.0 → v1.44.0

Change Log

• deleted: CVE-2026-33814.patch
• deleted: CVE-2026-39821.patch
• deleted: CVE-2026-56852.patch
• new file: CVE-2026-84445.patch
• new file: generate_source_tarball.sh
• modified: kata-containers-cc.signatures.json
• modified: kata-containers-cc.spec

Does this affect the toolchain?

NO

Links to CVEs

• https://nvd.nist.gov/vuln/detail/CVE-2026-84445
• https://nvd.nist.gov/vuln/detail/CVE-2026-84304

Test Methodology

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Akhila Guruju (akhila-guruju)]

Review: vendor-tarball / grpc module upgrade

Reviewed at head 3616c571. Because the fix ships inside an opaque vendor tarball, I downloaded the actual artifact from the source store and verified its contents rather than relying on the spec diff, changelog, or build status.

Note: the vendor tarball is Source2 in this spec — Source1 remains the cargo tarball.

---

Patch Analysis

• CVE-2026-84445 (gRPC-Go xDS server panic on missing :authority/Host) — delivered by module upgrade, not a backport. Vendored grpc is genuinely v1.83.2 (vendor/modules.txt:630, version.go → const Version = "1.83.2"). OSV GO-2026-6443 resolved by bump.
• CVE-2026-84304 (heap exhaustion via HTTP/2 DATA frame fragmentation) — same upgrade. OSV GO-2026-6348 resolved by bump.
• CVE-2026-33814 (removed patch) — clean reverse-apply against the new tree; fix present verbatim in golang.org/x/net v0.58.0.
• CVE-2026-39821 (removed patch) — reverse-apply fails at hunk Enable kdump support #9, context drift only. Fix present in refactored upstream form in x/net v0.58.0 idna.go process():
  if err == nil && len(u) > 0 && isASCII(u) { err = punyError(enc) }
  Obsolete idna9.0.0.go / tables9-13 / trie12-13 / go118.go are gone and tables17.0.0.go is present. Security property holds.
• CVE-2026-56852 (removed patch) — reverse-apply fails at hunk Fix filename issue that prevents successful git clone #1 because upstream rewrote the adjacent "4 bits" → "6 bits" comment. Fix present in x/text v0.41.0: isInvalid() (forminfo.go:128), size-0 guard Properties{flags: 0x80, size: 1} (:255), qcInfo(v>>8) & 0x3f (:264), 9 isInvalid() call sites in normalize.go, and zero residual size == 0 patterns.
• Also fixed by this bump but not mentioned in the changelog: CVE-2026-84303, CVE-2026-33186.

---

Vendor tarball verification

Check	Result
SHA256	Published blob 214a34c5…de84ef matches signatures.json ✅ (Source0/Source1 also match)
Module version	# google.golang.org/grpc v1.83.2 ✅ — patched go.mod agrees; all 9 claimed bumps agree between go.mod and modules.txt
go.sum provenance	9/9 h1: + /go.mod pairs verified against sum.golang.org; proxy.golang.org confirms v1.83.2 = grpc-go tag commit 030ee8becb20ce4315d6bf2dfa26bdd876169dc4
Packing	Single root src/runtime/vendor (correct for this spec's rm -rf + extract-at-source-root model), no absolute paths, no ../, no nested <pkg>-<ver>/
Reproducibility flags	All entries 0/0 owner/group, uniform mtime 2021-04-26 00:00, 0 PaxHeaders
Independent rebuild	Bit-for-bit reproduced — go.mod, go.sum, vendor/modules.txt IDENTICAL; diff -rq = 0 differences across 3705 files / 127 modules
Build ordering	Confirmed from the real rpmbuild log: Source0 → cd → Source1 cargo → rm -rf src/runtime/vendor → tar -xf Source2 → 12 × patch -p1 --fuzz=0 ✅
Patch application	All 12 apply at --fuzz=0. Offsets only (P7 −1, P9 −1, P10 +21) — zero fuzz, zero failures
Renumbering	Patch0..11 sequential, no gaps/duplicates, relative order preserved, every file exists
Vulnerability delta	20 changed / 1 added / 2 removed modules. Zero NEWLY INTRODUCED. 51 residual findings are all in unchanged modules (containerd 1.7.27, podman 4.9.4, runc 1.1.12, cilium/ebpf 0.9.1) = pre-existing

---

⚠️ Concern — the -czf change desynced the script from the pinned artifact

The latest commit flips -cf → -czf, which is the right fix, but it changes the tarball hash and nothing else was updated:

old -cf  output : 214a34c598dc…de84ef   (35.5 MB, POSIX tar)  <- still in blob store, still in signatures.json
new -czf output : f48df3455e8d…cd748d   ( 6.4 MB, real gzip)  <- what the script now produces

I re-ran the script's exact tar invocation both ways against my independently reproduced vendor tree: -cf reproduces the pinned hash exactly; -czf does not.

Consequences:

• ✅ No build breakage today — the blob store still serves the uncompressed tar and signatures.json still pins it, so rpmbuild is unaffected.
• ❌ The repo is now self-inconsistent — generate_source_tarball.sh at head no longer regenerates the artifact the build consumes. The next person to run it gets a signature mismatch.
• ❌ The intended ~82% size saving is not actually realized, since the published blob is unchanged.

To resolve, pick one:

1. Regenerate + re-upload the tarball with -czf and update signatures.json to
   f48df3455e8dc13405b7a29a7f7493d4c7b31b35af9c97e71dc1ecfa22cd748d, then re-run the buddy build; or
2. Revert to -cf.

If you take option 1, consider pinning the compressor so the hash is stable across machines (gzip output varies by implementation/level — it was stable across runs here on gzip 1.14 with header MTIME=0):

--use-compress-program='gzip -n -9'

Also, the commit message "remove comments from script" doesn't describe this change — worth amending so a hash-affecting edit is discoverable in history.

---

Non-blocking

1. Generator version-string fragility — NAME_VER="kata-containers-$PKG_VERSION.aks0" while Version: is already 3.15.0.aks0. Passing the conventional --pkgVersion %{version} yields kata-containers-3.15.0.aks0.aks0 and fails. Either take the full version or document that --pkgVersion 3.15.0 is required.
2. Changelog under-reports — CVE-2026-84303 and CVE-2026-33186 are also fixed here but not listed.
3. BuildRequires: golang is unversioned — grpc v1.83.2 forces the module's go directive from 1.21 → 1.25.0. The build succeeded, so azl3's golang satisfies it, but an explicit golang >= 1.25 would make that dependency non-implicit.
4. No %check section in the spec (absent on base too) — there's no go test -mod=vendor evidence for this package. Pre-existing, not introduced here.
5. go build akhila. fails on pkg/katautils (undefined: defaultHypervisorPath, …) — I reproduced this identically on the pristine unpatched tree; config-generated.go is Makefile-generated at build time. Not a regression. All vendored grpc packages and all otel packages build rc=0, and go list -mod=vendor with GOPROXY=off succeeds (57 packages), proving go.mod ↔ modules.txt consistency.
6. Pre-existing, not introduced — otel/sdk CVE-2026-81870 and x/mod CVE-2026-56864 / CVE-2026-56865 are reported at both the old and new versions.
7. cel.dev/expr and github.com/google/cel-go are neither vendored in src/runtime, so any CEL-related CVE is N/A for this tarball.
8. Sibling SPECS/kata-containers (3.32.0.kata0, different upstream tree) is unassessed — worth a separate check, out of scope here.

---

Verdict

Concerns — the security fix itself is fully proven: correct module version, verified upstream provenance, bit-for-bit reproducible vendor tree, zero newly introduced CVEs, and a clean build at release -21. The blocker is housekeeping: the -czf change needs a regenerated tarball + updated signatures.json, or a revert.

• Patch applies cleanly — all 12 at --fuzz=0 locally and in the real rpmbuild %prep; zero fuzz, zero failures
• Fix matches upstream — grpc v1.83.2 = upstream tag commit 030ee8be; go.sum verified against sum.golang.org; all 3 removed patches confirmed superseded (1 verbatim, 2 in identified refactored form)
• Spec metadata correct — Release 20→21, Patch0..11 sequential and order-preserving, changelog newest-first with all 12 weekday/date pairs valid, [High] matches HIGH CVSS on both CVEs, security label present, fasttrack/3.0 base appropriate
• Build passes — the build is green (Built (kata-containers-cc-3.15.0.aks0-21.azl3.src.rpm), both RPMs produced, correct %prep ordering, zero patch errors), but that evidence predates the -czf commit. A fresh build is needed once the tarball/signature question is settled.

_{Verified from an rpmbuild log at the matching NEVR; the ADO buddy-build artifact was not reachable from my environment and the GitHub API was rate-limited, so gh pr checks status is unverified.}

[Akhila Guruju (akhila-guruju)]

Buddy Build