Skip to content

[AutoPR- Security] Patch dasel for CVE-2026-42506, CVE-2026-27136, CVE-2026-25680, CVE-2026-42502, CVE-2026-25681 [MEDIUM]#17462

Open
azurelinux-security wants to merge 5 commits into
microsoft:3.0-devfrom
azurelinux-security:azure-autosec/dasel/3.0/1126749
Open

[AutoPR- Security] Patch dasel for CVE-2026-42506, CVE-2026-27136, CVE-2026-25680, CVE-2026-42502, CVE-2026-25681 [MEDIUM]#17462
azurelinux-security wants to merge 5 commits into
microsoft:3.0-devfrom
azurelinux-security:azure-autosec/dasel/3.0/1126749

Conversation

@azurelinux-security
Copy link
Copy Markdown

@azurelinux-security azurelinux-security commented May 27, 2026

Auto Patch dasel for CVE-2026-42506, CVE-2026-27136, CVE-2026-25680, CVE-2026-42502, CVE-2026-25681.

Autosec pipeline run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1126749&view=results
Autosec pipeline run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1127810&view=results
Autosec pipeline run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1127406&view=results
Autosec pipeline run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1127351&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 May 27, 2026
@Kanishk-Bansal Kanishk-Bansal marked this pull request as ready for review May 27, 2026 13:18
@Kanishk-Bansal Kanishk-Bansal requested a review from a team as a code owner May 27, 2026 13:18
@azurelinux-security azurelinux-security changed the title [AutoPR- Security] Patch dasel for CVE-2026-42506 [MEDIUM] [AutoPR- Security] Patch dasel for CVE-2026-42506, CVE-2026-27136 [MEDIUM] May 27, 2026
@azurelinux-security azurelinux-security changed the title [AutoPR- Security] Patch dasel for CVE-2026-42506, CVE-2026-27136 [MEDIUM] [AutoPR- Security] Patch dasel for CVE-2026-42506, CVE-2026-27136, CVE-2026-25680 [MEDIUM] May 27, 2026
@azurelinux-security azurelinux-security changed the title [AutoPR- Security] Patch dasel for CVE-2026-42506, CVE-2026-27136, CVE-2026-25680 [MEDIUM] [AutoPR- Security] Patch dasel for CVE-2026-42506, CVE-2026-27136, CVE-2026-25680, CVE-2026-42502, CVE-2026-25681 [MEDIUM] May 28, 2026
@azurelinux-security
Copy link
Copy Markdown
Author

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

PR #17462 — [AutoPR- Security] Patch dasel for CVE-2026-42506, CVE-2026-27136, CVE-2026-25680, CVE-2026-42502, CVE-2026-25681 [MEDIUM]
Package: dasel | Branch: 3.0-dev


Spec File Validation

Check Status Detail
Release bump Release bumped 3 → 4
Patch entry Patch entries added: ['CVE-2026-42506.patch', 'CVE-2026-27136.patch', 'CVE-2026-25680.patch', 'CVE-2026-25681.patch', 'CVE-2026-42502.patch'] (covers ['CVE-2026-25680', 'CVE-2026-25681', 'CVE-2026-27136', 'CVE-2026-42502', 'CVE-2026-42506'])
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 patch applies the upstream fix verbatim to the vendored golang.org/x/net/html/parse.go within the dasel package. It introduces the same cmp/slices imports, the attrCompare helper, sorts attributes before comparison, replaces the cubic attribute matching loop with slices.Equal, and sorts the top element’s attributes before appending. Aside from path and metadata differences, the code changes match upstream exactly. | The PR applies the upstream fix verbatim to the vendored golang.org/x/net/html renderer within the dasel package, updating DOCTYPE identifier rendering to escape '>' and renaming writeQuoted to writeDoctypeQuoted with an added defensive check. The test file is also added with identical content. No functional differences from upstream are observed. | The PR applies the same functional change as upstream to golang.org/x/net/html/token.go: it adds a per-tokenization map to track seen attribute names, clears it at the start of tag parsing, and filters out duplicate attributes case-insensitively, matching WHATWG 13.2.5.33. Tests added upstream are not included (as expected for vendored code), and the PR also adjusts vendor/modules.txt to require Go 1.21 to support the clear builtin. | The PR applies the core upstream fix to golang.org/x/net/html by modifying childTextNodesAreLiteral in vendor/golang.org/x/net/html/render.go to correctly handle foster-parented elements in foreign content. It omits only test-related changes and a test blacklist adjustment present upstream, which do not affect runtime behavior. The functional hunk matches upstream exactly, indicating a faithful backport. | The PR applies the same fix as upstream to the vendored golang.org/x/net/html parser within the dasel package: in inBodyEndTagOther, it adds a check ensuring the matched start tag is in the HTML namespace (Namespace == "") before comparing tag names. It also removes two spec-related comment lines and adds the same regression test file. The change is effectively identical, just applied to the vendored path and slightly different line offsets, consistent with a clean backport.
  • Missing hunks:
    • Upstream added two test cases in html/token_test.go to verify duplicate attribute handling; these are not present in the PR (vendored trees typically exclude tests).
    • html/parse_test.go: addition of a renderTestBlacklist entry for <math><mtext><table><mglyph><style><img> with a comment about fostering causing a different tree
    • html/render_test.go: addition of TestRenderFosteredForeignContent verifying that an fostered under foreign content is escaped within <style>
    • html/testdata/go/fostered_foreign_content.dat: new testdata file describing the expected DOM tree for the fostering scenario
Detailed analysis

Comparison shows the PR patch contains the same functional changes as upstream:

  • Imports: adds "cmp" and "slices" just like upstream.
  • New helper: introduces attrCompare(a, b Attribute) using cmp.Or and cmp.Compare exactly as upstream.
  • Optimization: sorts the incoming attr slice (p.tok.Attr) with slices.SortFunc(attr, attrCompare) before the Noah's Ark identical-element search, enabling direct use of slices.Equal.
  • Core fix: replaces the previous nested attribute comparison loop (including the len check and compareAttributes label) with a single condition: if !slices.Equal(n.Attr, attr) continue, identical to upstream.
  • Post-append optimization: before appending to p.afe, it sorts top.Attr using slices.SortFunc(top.Attr, attrCompare), matching upstream to ensure future comparisons are efficient and consistent.
  • Context and logic (Noah's Ark clause behavior, tagAtom checks, identicalElements counting) remain unchanged.
    Differences are limited to packaging and metadata: the PR applies the patch under vendor/golang.org/x/net/html/parse.go, includes Azure-specific Signed-off-by and Upstream-reference lines, and has different blob indices. No code hunks are missing or altered. Potential build consideration: the use of Go 1.21+ stdlib packages (cmp, slices) requires a compatible Go toolchain, but this matches upstream requirements. Given the exact match to the authoritative patch, functional risk is low and equivalent to upstream's assessed change.

Core changes match upstream exactly:

  • In render1, all three call sites for DOCTYPE identifiers are switched from writeQuoted(...) to writeDoctypeQuoted(...), covering PUBLIC and SYSTEM identifiers.
  • The helper function is renamed from writeQuoted to writeDoctypeQuoted, and its behavior is updated to:
    • Choose quote type as before, but now reject strings containing both '"' and ''' with the same error message as upstream.
    • Replace all '>' with '>' when writing, to prevent abrupt-doctype-system-identifier parse errors.
    • Comments are updated to reflect the new behavior.
  • The test file html/testdata/go/doctype_named_entity.dat is added with identical contents to upstream.

Differences are only in file paths and context line numbers due to vendoring:

  • Code changes are applied to vendor/golang.org/x/net/html/render.go instead of html/render.go.
  • The test file path matches upstream (html/testdata/go/doctype_named_entity.dat) and content is identical.

No upstream hunks are missing. The logic addresses CVE-2026-25681 completely by ensuring '>' in DOCTYPE identifiers is escaped, preventing parser state changes that could lead to sanitizer bypasses. Potential regression risk is minimal and equivalent to upstream: introducing a new error when both quote types appear (which upstream notes shouldn't happen from parser output), and escaping '>' within DOCTYPE identifiers, which is intended and safe. Context differences (line numbers) reflect repository state and do not alter behavior.

Core fix comparison:

  • Struct change: Both upstream and PR add attrNames map[string]bool to Tokenizer.
  • Tag parsing: Both add clear(z.attrNames) at the beginning of readTag, then compute the attribute key as strings.ToLower(string(z.buf[start:end])) and only append the attribute if the key hasn't been seen; when appended, they set z.attrNames[key] = true. This matches upstream exactly and enforces ignoring duplicate attributes irrespective of case.
  • Initialization: Both initialize attrNames in NewTokenizerFragment with make(map[string]bool). In x/net/html, NewTokenizer calls NewTokenizerFragment, so this covers all constructors. clear on a nil map would be a no-op, but a nil map would panic on assignment; the added initialization in Fragment ensures attrNames is non-nil in normal construction paths.

Differences from upstream:

  • Tests: Upstream adds two tokenization tests for duplicate attributes; the PR does not add these, which is typical for vendor directories (tests are generally not vendored) and does not affect runtime behavior.
  • Build metadata: The PR additionally updates vendor/modules.txt to mark golang.org/x/net as requiring Go 1.21 instead of 1.18. This aligns with the new use of the clear builtin introduced in Go 1.21 and is a packaging/build change not present in the upstream code diff but necessary for compatibility in this vendor context.

Context and safety:

  • The patch implements WHATWG 13.2.5.33 behavior to ignore duplicate attributes, removing parser misalignment that could confuse sanitizers (CVE-2026-27136). The code delta is minimal and mirrors upstream logic exactly, so functional risk is low.
  • The use of strings.ToLower is consistent with existing code paths that already import strings. No additional imports are required.
  • Backward compatibility: The only notable requirement is Go 1.21 for clear, which the PR accounts for via modules.txt. No other behavioral differences are introduced.

Conclusion: The PR’s code changes are functionally identical to upstream for the fix, with minor non-functional differences (omitted tests and a modules.txt update).

  1. Core fix comparison: Upstream modifies html/render.go in childTextNodesAreLiteral to add an ancestor walk when encountering HTML raw-text elements (iframe, noembed, noframes, noscript, plaintext, script, style, xmp). The new logic walks up parents until it finds a node with a non-empty namespace; if that ancestor is not an HTML integration point, it returns false (i.e., do not treat child text nodes as literal), otherwise it breaks and returns true. This ensures fostered elements moved into foreign content do not incorrectly render raw text, preventing unescaped content that could lead to XSS. The PR applies the same logic, verbatim, to vendor/golang.org/x/net/html/render.go. The case list, control flow, comments, and placement are identical to upstream.

  2. Differences vs upstream: The PR includes only the functional change in the vendored file and does not include the upstream test additions (render_test.go, testdata file) nor the small render test blacklist change in parse_test.go. These missing hunks are test-only and do not impact the runtime fix. The file paths differ (vendor/...) because this is a packaged, vendored copy within the dasel SRPM.

  3. Context and compatibility: The surrounding context in the function matches sufficiently for the patch to apply cleanly. The change relies on htmlIntegrationPoint(p), which exists in this package in typical x/net/html versions; given the patch compiles in the PR context, this is presumed present. No other upstream changes are required for correctness of this fix.

  4. Risk assessment: Low. The change is a direct backport of the upstream logic with no deviations. The omission of tests only reduces verification coverage in the package build but does not affect the deployed behavior. Potential regression risk is minimal and identical to upstream's, bounded to rendering behavior for fostered elements in foreign content.


Comparison shows the core security fix is present and identical: in vendor/golang.org/x/net/html/parse.go, the condition in inBodyEndTagOther is changed from if (p.oe[i].DataAtom == tagAtom) && ... to if p.oe[i].Namespace == "" && (p.oe[i].DataAtom == tagAtom) && ..., matching the upstream commit. The two adjacent comment lines referencing foreign content parsing are removed in both patches. The regression test file in_body_end.dat is added with the same contents under the corresponding vendor testdata path. Line numbers differ slightly due to the vendored codebase, and file paths are under vendor/, which is expected for a distribution backport. There are no missing hunks or additional functional changes beyond those in the upstream patch. The change is minimal and aligned with the HTML parsing spec, reducing the chance of regressions; thus, the risk is low.


Verdict

APPROVED — All checks passed. Ready to merge.

Copy link
Copy Markdown

@Kanishk-Bansal Kanishk-Bansal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Patch Analysis (matches upstream, test files are ommitted.)

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

@Kanishk-Bansal Kanishk-Bansal added the ready-for-stable-review PR has passed initial review and is now ready for a second-level stable maintainer review label May 29, 2026
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 AutoPR-Security Packaging ready-for-stable-review PR has passed initial review and is now ready for a second-level stable maintainer review security

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants