[AutoPR- Security] Patch libreswan for CVE-2026-50722, CVE-2026-50721, CVE-2026-12413 [HIGH]

[azurelinux-security]

Auto Patch libreswan for CVE-2026-50722, CVE-2026-50721, CVE-2026-12413.

Autosec pipeline run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1152289&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 libreswan for CVE-2026-50722 (HIGH), CVE-2026-50721 (HIGH), CVE-2026-12413 (HIGH).

Change Log

• CVE-2026-50722
• CVE-2026-50721
• CVE-2026-12413

Does this affect the toolchain?

YES/NO

Associated issues

• N/A

Links to CVEs

• https://nvd.nist.gov/vuln/detail/CVE-2026-50722
• https://nvd.nist.gov/vuln/detail/CVE-2026-50721
• https://nvd.nist.gov/vuln/detail/CVE-2026-12413

Test Methodology

• Pipeline build id: Buddy Build URL

[Kanishk-Bansal]

Patch Analysis (all patches are taken from 4.15 supported patch galary from maintainers, they apply byte accurate)

• 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-2026-12413, CVE-2026-50721, CVE-2026-50722

PR #17904 — [AutoPR- Security] Patch libreswan for CVE-2026-50722, CVE-2026-50721, CVE-2026-12413 [HIGH]
Package: libreswan | Branch: fasttrack/3.0

---

Spec File Validation

Check	Status	Detail
Release bump	✅	Release bumped 1 → 2
Patch entry	✅	Patch entries added: ['CVE-2026-12413.patch', 'CVE-2026-50721.patch', 'CVE-2026-50722.patch'] (covers ['CVE-2026-12413', 'CVE-2026-50721', 'CVE-2026-50722'])
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: medium
• Summary: The libreswan RPM build completed successfully and produced both the main package and debuginfo RPMs. All three CVE patches (CVE-2026-12413, CVE-2026-50721, and CVE-2026-50722) were applied during %prep without any reported hunk failures, fuzz, or offset messages, and the package compiled, installed into BUILDROOT, and packaged cleanly. No compilation, linker, or test failures were observed; tests were disabled via --nocheck.
• AI-detected warnings:
  • Tests were not executed because rpmbuild was invoked with --nocheck and with_check 0, so runtime/regression validation of the CVE backports was not performed in this build.
  • During install, /bin/sh reported 'test: too many arguments' on lines 8 and 12 in the systemd-related install phase, but the build continued and completed successfully.
  • During debuginfo/source processing, cpio reported missing temporary/generated files under lib/libipsecconf (lex.yy.c.tmp, parser.tab.c.tmp, parser.tab.h); this did not fail the build but is worth checking for packaging hygiene.
  • RPM emitted hostname canonicalization warnings ('Could not canonicalize hostname'), which appear environmental and non-fatal.

---

🧪 Test Log Analysis

• Test status: ❌ FAILED
• Test errors (69):
  • L4207: time="2026-07-03T10:07:38Z" level=debug msg="\tERROR: ESP proposal is empty"
  • L4229: time="2026-07-03T10:07:38Z" level=debug msg="\tERROR: ESP DH algorithm 'modp1024' is not supported"
  • L4239: time="2026-07-03T10:07:38Z" level=debug msg="\tERROR: ESP DH algorithm 'dh23' is not supported"
  • L4241: time="2026-07-03T10:07:38Z" level=debug msg="\tERROR: ESP DH algorithm 'dh24' is not supported"
  • L4425: time="2026-07-03T10:07:38Z" level=debug msg="\tERROR: ESP encryption algorithm 3DES_CBC does not allow a key lengths"
  • L4427: time="2026-07-03T10:07:38Z" level=debug msg="\tERROR: non-AEAD ESP encryption algorithm 3DES_CBC cannot have 'NONE' as the integrity algorithm"
  • L4429: time="2026-07-03T10:07:38Z" level=debug msg="\tERROR: non-AEAD ESP encryption algorithm AES_CBC cannot have 'NONE' as the integrity algorithm"
  • L4431: time="2026-07-03T10:07:38Z" level=debug msg="\tERROR: ESP encryption algorithm AES_CBC with key length 224 invalid; valid key lengths: 128, 192, 256"
  • L4433: time="2026-07-03T10:07:38Z" level=debug msg="\tERROR: ESP encryption algorithm AES_CBC with key length 224 invalid; valid key lengths: 128, 192, 256"
  • L4435: time="2026-07-03T10:07:38Z" level=debug msg="\tERROR: ESP encryption key length is zero"
  • … and 59 more
• Test warnings (1):
  • L4730: time="2026-07-03T10:07:38Z" level=debug msg="/usr/src/azl/BUILDROOT/libreswan-4.15-2.azl3.x86_64/usr/libexec/ipsec/pluto: pluto: warning: chdir(\"/run/pluto\") to dumpdir failed (2: No such file or directory)"

🤖 AI Test Log Analysis

• Risk: low
• Summary: The libreswan build and %check phase completed successfully with exit status 0 after applying the CVE-2026-12413, CVE-2026-50721, and CVE-2026-50722 patches. The visible test coverage includes successful algorithm parser validation and a successful pluto self-test using a temporary NSS database. No test failures, crashes, or obvious regressions are shown in the log, and the patched package built cleanly enough to finish packaging.

---

Patch Analysis

• Match type: significant_differences
• Risk assessment: medium
• Summary: The PR patch is functionally identical to the upstream CVE fix. It applies the same single code change in programs/pluto/ikev2_message.c, changing the assertion from md->digest_roof < elemsof(md->digest) to md->digest_roof <= elemsof(md->digest). The only differences are patch-wrapper metadata and packaging location (SPECS/libreswan/CVE-2026-12413.patch), not code semantics. | The core security fix applied to lib/libswan/pubkey_rsa.c is functionally equivalent to upstream: it replaces manual RSA signature recovery and suffix-based hash comparison using PK11_VerifyRecover() with NSS's PK11_Verify() over SECItems derived from the signature and expected hash. However, the PR patch also deletes four unrelated packaging/testing patch files that are not part of the upstream CVE fix. Because the PR materially changes files outside the scope of the authoritative patch, it is not an exact or clean backport of the upstream CVE fix despite containing the essential remediation hunk. | The PR patch is functionally equivalent to the upstream CVE fix. It applies the same code changes to lib/libswan/pubkey_rsa.c: replacing the unused hash algorithm parameter with a real hash_alg parameter, removing the manual PK11_VerifyRecover-based signature decryption and suffix comparison logic, and switching to NSS's VFY_VerifyDigestDirect() with the supplied hash OID. The only differences are packaging/metadata wrapper lines because the PR adds the upstream change as a new spec patch file for Azure Linux rather than presenting the raw upstream diff directly.

Detailed analysis

Core fix equivalence: yes. Upstream contains one hunk affecting reassemble_v2_incoming_fragments() and the PR reproduces that exact hunk with the same old and new code. There are no omitted code hunks, no altered logic, and no additional behavioral changes. Differences vs upstream are limited to the PR being stored as a downstream patch file with email-style patch headers (From, Subject, Signed-off-by, Upstream-reference) and abbreviated blob IDs (84b289c..a691346 instead of full hashes), which is normal for distro packaging and has no effect on the applied source change. This is not really a semantic backport with adapted logic; it is the same one-line fix carried as a packaging patch. Context lines match the upstream location and appear safe. Because the patch is minimal and exactly mirrors upstream, the risk of incompleteness or regression relative to the authoritative fix is low.

For the actual vulnerability remediation, the PR matches upstream in substance. In RSA_authenticate_signature_raw_rsa(), it removes allocation of a decrypted_signature buffer, removes SECITEM_AllocItem(), removes construction of encrypted_signature via DISCARD_CONST(), removes PK11_VerifyRecover(), removes debug logging of the decrypted signature, removes the manual 'hash appears at end of decrypted block' validation logic, and instead constructs signature_secitem and expected_hash_secitem using same_shunk_as_secitem()/HUNK_AS_SHUNK() and calls PK11_Verify(). That is the key security behavior change from upstream, and the surrounding control flow and error handling are effectively the same: on verification failure it logs, sets *fatal_diag = NULL, and returns false; on success it clears fatal_diag and returns true. This looks like a straightforward patch-file packaging of the upstream code hunk, with only expected metadata/context differences. There are no missing hunks from the upstream fix itself.

The significant divergence is that the PR patch also deletes unrelated files: packaging/debian/patches/0002-debian-pam.d-pluto.patch, packaging/devuan/patches/0002-debian-pam.d-pluto.patch, testing/pluto/delete-sa-02/libreswan-3.23-del-notify.patch, and testing/pluto/delete-sa-02/libreswan-3.23-impair-del-notify.patch. These deletions do not appear in the authoritative upstream CVE patch and are unrelated to the RSA verification flaw. This makes the PR patch broader than the upstream security fix and potentially disruptive to downstream packaging or test assets. Even if those files are obsolete in Azure Linux, bundling their removal into the CVE patch is a substantive difference and complicates review/auditability. So while the security hunk is equivalent, the overall PR patch is not equivalent to upstream as a whole and should be treated as having significant differences. Regression risk from the core fix itself appears low-to-medium, but the unrelated file deletions elevate overall risk to medium because they may affect packaging workflows or downstream test coverage.

Reviewing the actual code hunk inside the packaged patch shows it matches upstream on all security-relevant points. First, the function signature is updated identically from 'unused_hash_algo UNUSED' to 'hash_alg', enabling use of the caller-provided digest algorithm. Second, the old implementation that allocated a decrypted_signature buffer, called PK11_VerifyRecover(), logged the recovered signature, and accepted any decrypted blob whose trailing bytes matched expected_hash is removed exactly as upstream does. Third, the replacement logic is identical: it constructs 'hash_item' from expected_hash and 'signature_item' from signature using same_shunk_as_secitem(), then calls VFY_VerifyDigestDirect() with SEC_OID_PKCS1_RSA_ENCRYPTION and hash_alg->nss.oid_tag, failing with ldbg_nss_error() and returning false on verification failure. The cleanup behavior also matches upstream: the explicit SECITEM allocation/free path is gone because no temporary decrypted buffer is used. There are no missing hunks from the authoritative patch. The only observable differences are non-functional patch wrapper metadata (From, Subject, Signed-off-by, Upstream-reference, git version footer, and placement under SPECS/libreswan/CVE-2026-50722.patch), which are expected for a downstream packaging backport and do not alter the code change. Because the core logic is identical, the risk of incompleteness relative to upstream is low; regression risk is the same as upstream's intended behavioral tightening, namely that previously accepted malformed PKCS#1 v1.5 RSA signatures will now be correctly rejected by NSS's direct digest verification.

---

Verdict

❌ CHANGES REQUESTED — Please address the issues flagged above.