[AutoPR- Security] Patch python-pyasn1 for CVE-2026-59886, CVE-2026-59885, CVE-2026-59884 [HIGH]

[azurelinux-security]

Auto Patch python-pyasn1 for CVE-2026-59886, CVE-2026-59885, CVE-2026-59884.

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

CVE-2026-59885 : Single Patch Backporter Pipeline Run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1161912&view=results
CVE-2026-59884 : Single Patch Backporter Pipeline Run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1161911&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?

• Auto Patch python-pyasn1 for CVE-2026-59886 (HIGH), CVE-2026-59885 (HIGH), CVE-2026-59884 (HIGH).

Change Log

• CVE-2026-59886
• CVE-2026-59885
• CVE-2026-59884

Does this affect the toolchain?

YES/NO

Associated issues

• N/A

Links to CVEs

• https://nvd.nist.gov/vuln/detail/CVE-2026-59886
• https://nvd.nist.gov/vuln/detail/CVE-2026-59885
• https://nvd.nist.gov/vuln/detail/CVE-2026-59884

Test Methodology

• Pipeline build id: Buddy Build URL

[azure-pipelines]

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

[Kanishk-Bansal]

• CVE-2026-59884 (tag.py + decoder.py) — ❌ Incomplete — the CVE is only half-fixed. AI Backport of 628e36ec.

  • tag.py half ("huge tag repr") — byte-identical to upstream, applied correctly. ✅
  • decoder.py half ("long tag bounds") — the enforcement was dropped. Upstream adds MAX_TAG_OCTETS = 20 and the guard inside the long-form tag decode loop:

    tagOctetCount += 1
    if tagOctetCount > MAX_TAG_OCTETS:
        raise error.PyAsn1Error('Tag ID octet count exceeds limit (%d)' % (MAX_TAG_OCTETS,))

    The PR adds only the MAX_TAG_OCTETS = 20 constant — which is referenced nowhere (dead constant). I confirmed AL's 0.4.8 base decoder.py does have the exact target loop (if tagId == 0x1F: … lengthOctetIdx += 1; tagId <<= 7), so the guard was fully backportable. Result: the decoder-side unbounded long-form tag-ID DoS is not mitigated — an attacker can still feed an arbitrarily long high-tag-number encoding.

  Fix: in decoder.py's if tagId == 0x1F: loop, add after lengthOctetIdx += 1:

  if lengthOctetIdx > MAX_TAG_OCTETS:
      raise error.PyAsn1Error('Tag ID octet count exceeds limit (%d)' % (MAX_TAG_OCTETS,))

[BinduSri-6522866]

CVE-2026-59884: Backported suggested fix from above comment for decoder.py and imported encoder in test files to support upstream logic.
CVE-2026-59885: class RelativeOIDPayloadDecoder in 'decoder.pyandclass RelativeOIDEncoderinencoder.py` are not present in our source code, so respective code and tests cases were not included in patch.
CVE-2026-59886: Same as upstream patch.

Buddy build passed - https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1162885&view=results
Three test failures from test log are pre-existed, not related to above three patches.