Skip to content

[AutoPR- Security] Patch multus for CVE-2026-42502, CVE-2026-25681, CVE-2026-25680 [MEDIUM]#17580

Open
azurelinux-security wants to merge 1 commit into
microsoft:3.0-devfrom
azurelinux-security:azure-autosec/multus/3.0/1130161
Open

[AutoPR- Security] Patch multus for CVE-2026-42502, CVE-2026-25681, CVE-2026-25680 [MEDIUM]#17580
azurelinux-security wants to merge 1 commit into
microsoft:3.0-devfrom
azurelinux-security:azure-autosec/multus/3.0/1130161

Conversation

@azurelinux-security
Copy link
Copy Markdown

@azurelinux-security azurelinux-security commented Jun 1, 2026

Auto Patch multus for CVE-2026-42502, CVE-2026-25681, CVE-2026-25680.

Autosec pipeline run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1130161&view=results

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?

Change Log
Does this affect the toolchain?

YES/NO

Associated issues
  • N/A
Links to CVEs
Test Methodology

@microsoft-github-policy-service microsoft-github-policy-service Bot added Packaging 3.0-dev PRs Destined for AzureLinux 3.0 labels Jun 1, 2026
@azurelinux-security
Copy link
Copy Markdown
Author

🔒 CVE Patch Review: CVE-2026-25680, CVE-2026-25681, CVE-2026-42502

PR #17580 — [AutoPR- Security] Patch multus for CVE-2026-42502, CVE-2026-25681, CVE-2026-25680 [MEDIUM]
Package: multus | Branch: 3.0-dev


Spec File Validation

Check Status Detail
Release bump Release bumped 8 → 9
Patch entry Patch entries added: ['CVE-2026-25680.patch', 'CVE-2026-25681.patch', 'CVE-2026-42502.patch'] (covers ['CVE-2026-25680', 'CVE-2026-25681', 'CVE-2026-42502'])
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 log analysis was skipped (no build ID available).


Patch Analysis

  • Match type: backport
  • Risk assessment: low
  • Summary: The PR applies the upstream fix verbatim to the vendored golang.org/x/net/html parser: it adds cmp and slices imports, introduces attrCompare, sorts attribute slices for comparison and storage, and replaces the cubic attribute-comparison loop with slices.Equal. Aside from path and metadata differences (vendor path and added Signed-off-by/Upstream-reference), the code changes match upstream exactly. | The PR applies the upstream fix to the vendored golang.org/x/net/html package, renaming writeQuoted to writeDoctypeQuoted, updating the three DOCTYPE call sites, and escaping '>' as > within doctype identifiers. It also adds the same test file. Aside from path and context differences due to vendoring/older file offsets, the code changes match upstream and implement the same security mitigation for CVE-2026-25681. | The PR applies the upstream fix to golang.org/x/net/html by modifying childTextNodesAreLiteral to correctly handle foster-parented elements in foreign content, ensuring raw-text elements are escaped when fostered under a non-HTML namespace without an HTML integration point. It matches the upstream functional change, but omits upstream test additions and a test blacklist entry, consistent with a vendor backport.
  • Missing hunks:
    • Test blacklist addition in html/parse_test.go: adds a comment and the entry <math><mtext><table><mglyph><style><img> to renderTestBlacklist.
    • New test in html/render_test.go: TestRenderFosteredForeignContent to verify that inside <style> fostered into foreign content is escaped in the rendered output.
    • New test data file html/testdata/go/fostered_foreign_content.dat describing the expected parse tree.
Detailed analysis

Comparison of hunks shows the PR patch makes identical code changes to upstream, just applied to vendor/golang.org/x/net/html/parse.go instead of html/parse.go. Specifically: (1) import additions of "cmp" and "slices" are present; (2) a new attrCompare(a, b Attribute) function using cmp.Or and cmp.Compare on Namespace, Key, and Val is added; (3) in addFormattingElement, the attribute slice from the token (attr) is sorted via slices.SortFunc(attr, attrCompare) before searching; (4) the previous nested attribute comparison loop is replaced by a single condition using slices.Equal(n.Attr, attr); and (5) after adding the element, the attributes on the top node are sorted with slices.SortFunc(top.Attr, attrCompare) before appending to p.afe. Comments and surrounding context match upstream. No hunks are missing, altered, or added beyond the upstream changes; differences are limited to the patch file location, git metadata, and an added Signed-off-by/Upstream-reference in the patch header. Risk is low as this is a performance fix accepted upstream; the primary consideration is that it introduces dependencies on the Go 1.21 standard library packages cmp and slices, which must be supported by the build toolchain. Attribute order is now normalized (sorted) on the newly added node in this code path, which upstream considered acceptable; functional behavior for equality checks and the Noah's Ark clause is preserved with improved performance.

Core fix equivalence: The PR changes vendor/golang.org/x/net/html/render.go in the same way as upstream:

  • In render1, all three invocations that print DOCTYPE identifiers are switched from writeQuoted(...) to writeDoctypeQuoted(...), covering PUBLIC identifiers (p), optional system identifier (s) following PUBLIC, and the SYSTEM case.
  • The helper is renamed and redefined: writeQuoted -> writeDoctypeQuoted with identical logic to upstream: choose quoting style (default ", switch to ' if s contains "), explicitly reject the unsafe case where both quote types appear by returning errors.New(...), and replace all '>' with ">" before writing. The comments added match upstream, including the rationale and the abrupt-doctype-system-identifier parse error prevention.
  • The PR includes the same test file vendor/golang.org/x/net/html/testdata/go/doctype_named_entity.dat with identical content, validating the behavior.
    Differences observed: The PR applies to a vendored path and shows different blob indices and context line numbers (e.g., the childTextNodesAreLiteral anchor at ~251 vs ~267 upstream), consistent with a backport to a slightly different base revision. No functional differences in the modified hunks were found. Import statements are not shown in either patch; upstream did not need to change imports, so errors and strings are presumed already imported in this render.go version in both trees. No additional or missing code changes relative to upstream’s fix were detected.
    Risk assessment: Low. The changes are localized to DOCTYPE rendering and match upstream’s vetted patch. Potential build risk would only arise if the vendored file lacked an import for errors, but upstream also did not adjust imports, suggesting both already have it. Functionally, the fix reduces the risk of parser state confusion by escaping '>' in identifiers and safely errors if both quote types are present in a user-constructed Node, aligning with upstream behavior.

Core fix equivalence: The PR modifies vendor/golang.org/x/net/html/render.go in childTextNodesAreLiteral exactly as upstream, inserting a parent-walk that checks for a non-empty namespace ancestor and verifies whether it is an HTML integration point. If a non-HTML integration point is encountered, it returns false, preventing raw-text rendering for fostered nodes in foreign content. The switch case set (iframe, noembed, noframes, noscript, plaintext, script, style, xmp) and logic are identical to upstream, including comments and control flow. Context alignment: The hunk applies at the same function and surrounding context as upstream (around line ~243), with only the added loop before returning true for the raw-text elements. Path/packaging differences: The change is applied to a vendored copy (vendor/golang.org/x/net/html/render.go) via SPECS/multus/CVE-2026-42502.patch rather than the upstream repository paths, which is normal for a distribution backport. Missing hunks: The PR does not include upstream test changes (parse_test.go blacklist entry, new render test, and testdata file). These omissions do not affect runtime behavior and are typical in packaging backports where tests may not be shipped or run. Risk assessment: Low. The change is narrowly scoped to rendering decisions for raw-text elements, aligns with upstream’s vetted fix, and reduces XSS risk by ensuring escaping when fostered into non-HTML namespaces without an integration point. Potential regressions are limited to correcting previously incorrect raw-text rendering in niche foster-parenting scenarios; no additional functional differences from upstream were observed.


Verdict

APPROVED — All checks passed. Ready to merge.

@Kanishk-Bansal Kanishk-Bansal marked this pull request as ready for review June 1, 2026 06:38
@Kanishk-Bansal Kanishk-Bansal requested a review from a team as a code owner June 1, 2026 06:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

3.0-dev PRs Destined for AzureLinux 3.0 Packaging

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant