[LOW] Patch kata-containers for CVE-2025-58160 and CVE-2026-27171

[archana25-ms]

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

• The toolchain has been rebuilt successfully (or no changes were made to it)
• The toolchain/worker package manifests are up-to-date
• Any updated packages successfully build (or no packages were changed)
• Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
• Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
• All package sources are available
• cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
• LICENSE-MAP files are up-to-date (./LICENSES-AND-NOTICES/SPECS/data/licenses.json, ./LICENSES-AND-NOTICES/SPECS/LICENSES-MAP.md, ./LICENSES-AND-NOTICES/SPECS/LICENSE-EXCEPTIONS.PHOTON)
• All source files have up-to-date hashes in the *.signatures.json files
• sudo make go-tidy-all and sudo make go-test-coverage pass
• Documentation has been updated to match any changes to the build system
• Ready to merge

---

Summary

What does the PR accomplish, why was it needed?
Patch kata-containers for CVE-2025-58160 and CVE-2026-27171

Change Log

• SPECS/kata-containers/CVE-2025-58160.patch
• SPECS/kata-containers/CVE-2026-27171.patch
• SPECS/kata-containers/kata-containers.spec

Does this affect the toolchain?

NO

Links to CVEs

• https://nvd.nist.gov/vuln/detail/CVE-2025-58160
• https://nvd.nist.gov/vuln/detail/CVE-2026-27171

Test Methodology

• Pipeline build id: xxxx

[Kanishk-Bansal]

BUDDY BUILD

[archana25-ms]

Build has been successful in VM and above is the screenshot of CVE patches getting applied.

[jykanase]

Buddy Build has passed

[akhila-guruju]

For CVE-2025-58160.patch,
nit: Indentation is missing for some of the lines R125, R134, R146

[akhila-guruju]

Buddy Build after recent changes

[akhila-guruju]

Patch Analysis:
Both the patches match with upstream patches. Slight variation around some of the patched lines. checksum.json files are updated with new shasum.
Vendor test file tracing-subscriber/tests/ansi_escaping.rs is not included in the azl patch.

• Buddy Build
• patch applied during the build (check rpm.log)
• patch include an upstream reference
• PR has security tag

[azurelinux-security]

🔒 CVE Patch Review: CVE-2025-58160, CVE-2026-27171

PR #16007 — [LOW] Patch kata-containers for CVE-2025-58160 and CVE-2026-27171
Package: kata-containers | Branch: 3.0-dev

---

Spec File Validation

Check	Status	Detail
Release bump	✅	Release bumped 5 → 6
Patch entry	✅	Patch entries added: ['CVE-2025-58160.patch', 'CVE-2026-27171.patch'] (covers ['CVE-2025-58160', 'CVE-2026-27171'])
Patch application	✅	%autosetup/%autopatch found in full spec — patches applied automatically
Changelog	✅	Changelog entry looks good
Signatures	✅	No source tarball changes — signatures N/A
Manifests	✅	Not a toolchain PR — manifests N/A

---

Build Verification

• Build status: ✅ PASSED
• Artifact downloaded: ✅
• CVE applied during build: ✅

🤖 AI Build Log Analysis

• Risk: low
• Summary: The kata-containers RPM rebuild completed successfully and produced both the main package and the tools subpackage. The requested CVE patches for CVE-2025-58160 and CVE-2026-27171 were applied during %prep without any reported hunk failures, rejects, fuzz, or offset warnings, and the subsequent build/install/package phases completed cleanly. No compilation, linker, or test failures were observed; tests were explicitly skipped via --nocheck.
• AI-detected warnings:
  • The build log does not show per-hunk patch output because patch was invoked with silent mode (-s), so patch application success is inferred from the absence of failures rather than explicit hunk-by-hunk confirmation.
  • RPM emitted a hostname warning ('Could not canonicalize hostname'), but it did not affect the build.
  • Builds were run with --nocheck, so no test execution was performed and runtime/regression issues from the backported CVE fixes were not validated in this build.

---

🧪 Test Log Analysis

No test log found (package may not have a %check section).

---

Patch Analysis

• Match type: backport
• Risk assessment: medium
• Summary: The PR patch appears to be a backport of the upstream CVE fix into kata-containers' vendored tracing-subscriber tree rather than an exact copy of the upstream patch. The core security-relevant code changes are functionally equivalent: it adds the same escape.rs wrapper and applies ANSI/control-character escaping to message formatting, error display formatting, and error source-list formatting in both the default and pretty formatters. The main differences are expected backport/context adaptations to an older vendored version (ansi_term/older line offsets), plus omission of upstream version/changelog/test additions. Those omissions do not change the runtime fix, but they do reduce verification coverage in the downstream tree. | The PR patch carries the same substantive security fix as upstream: it adds negative-length guards returning 0 in the zlib crc32_combine64() and crc32_combine_gen64() code paths, and updates the corresponding zlib.h API comments to document that zero is returned for negative len2. The differences are packaging-related rather than behavioral: the patch is applied to the vendored zlib copy under src/agent/vendor/libz-sys/src/zlib/ instead of the upstream top-level files, and it also updates .cargo-checksum.json to keep the vendored Rust crate checksum metadata consistent.
• Missing hunks:
  • Upstream CHANGELOG.md update for tracing-subscriber 0.3.20 is not included.
  • Upstream Cargo.toml version bump from 0.3.19 to 0.3.20 is not included.
  • Upstream integration test file tracing-subscriber/tests/ansi_escaping.rs is not included in the PR.
  • PR adds vendored crate bookkeeping (.cargo-checksum.json) not present upstream, which is packaging-specific rather than security-functional.

Detailed analysis

The important question is whether the security fix itself matches upstream behavior, and on that point the PR is substantially aligned. First, it adds src/fmt/format/escape.rs with the same implementation as upstream: a streaming Escape<T> wrapper plus EscapingWriter that replaces raw ESC/BEL/BS/FF/DEL bytes and C1 control characters (0x80..=0x9f) with visible escaped representations. This is the core sanitization primitive and is identical in logic. Second, in src/fmt/format/mod.rs, the PR imports escape::Escape and applies it in the same security-sensitive paths as upstream: message rendering (field.name() == "message"), error Display formatting in record_error, and formatting of chained error sources via ErrorSourceList. Third, in src/fmt/format/pretty.rs, the PR likewise wraps pretty-formatted messages and error displays exactly as upstream intends. The surrounding context differs because this is clearly an older vendored tracing-subscriber revision: imports use ansi_term::{Colour, Style} instead of upstream's nu_ansi_term::{Color, Style}, line numbers differ substantially, and one upstream match arm shown as match name { ... name if name.starts_with("r#") ... } appears in the older codebase as match field.name() { ... } with different neighboring arms. Those are normal backport context differences and do not indicate a semantic deviation in the applied fix. What is missing versus upstream are non-runtime hunks: changelog/version bump and the new integration tests. The lack of tests is the main concern because it means downstream has less evidence that all formatter paths behave as intended in this older crate snapshot; however, the patched code paths themselves are present and consistent with upstream's fix strategy. I do not see evidence that the fix is incomplete in the touched default/pretty/error paths, and there is no sign of an unsafe adaptation beyond normal backporting. The residual risk is therefore moderate rather than high: not because the code differs materially, but because this is an older-tree backport without the accompanying upstream tests, so validation burden shifts to downstream build/test coverage.

Functionally, the core fix appears equivalent to upstream. Upstream modifies two implementation sites in crc32.c: adding if (len2 < 0) return 0; at the start of crc32_combine64() and crc32_combine_gen64(). The PR patch applies those same changes to the vendored file src/agent/vendor/libz-sys/src/zlib/crc32.c, which is the Azure Linux/Kata packaging location for the bundled zlib source. Upstream also changes two documentation lines in zlib.h so that crc32_combine() and crc32_combine_gen() explicitly state that negative len2 returns zero; the PR applies those same documentation updates in src/agent/vendor/libz-sys/src/zlib/zlib.h. There are no missing security-relevant hunks based on the supplied material. The only extra change versus upstream is the .cargo-checksum.json update, which is expected and necessary when patching vendored Cargo sources, and does not alter runtime behavior. This should be considered a packaging-adapted application of the upstream patch rather than a divergent implementation. Risk is low because the behavioral changes are minimal, directly mirror upstream, and are limited to rejecting invalid negative lengths early, reducing the chance of the previously noted infinite-loop condition without broad impact. The only caveat is that this assessment is limited to the vendored zlib instance shown; if Kata also uses another zlib implementation copy elsewhere, that would need separate verification, but within the patched tree the fix is complete and safely backported.

---

Verdict

✅ APPROVED — All checks passed. Ready to merge.

[Kanishk-Bansal]

Patch Analysis (security logic matches upstream, only checksum files are added extra)

• Buddy Build 
• patch applied during the build (check rpm.log)
• patch include an upstream reference
• PR has security tag

[kgodara912]

Core CVE fixes match with respective upstream references, checksum and other irrelevant files are extra. Buddy build is successful. LGTM.