[AutoPR- Security] Patch erlang for CVE-2026-54886 [MEDIUM]

[azurelinux-security]

Auto Patch erlang for CVE-2026-54886.

Autosec pipeline run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1154399&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 erlang for CVE-2026-54886 (MEDIUM).

Change Log

• CVE-2026-54886

Does this affect the toolchain?

YES/NO

Associated issues

• N/A

Links to CVEs

• https://nvd.nist.gov/vuln/detail/CVE-2026-54886

Test Methodology

• Pipeline build id: Buddy Build URL

[azurelinux-security]

🔒 CVE Patch Review: CVE-2026-54886

PR #17923 — [AutoPR- Security] Patch erlang for CVE-2026-54886 [MEDIUM]
Package: erlang | Branch: 3.0-dev

---

Spec File Validation

Check	Status	Detail
Release bump	✅	Release bumped 2 → 3
Patch entry	✅	Patch entries added: ['CVE-2026-54886.patch'] (covers ['CVE-2026-54886'])
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: minor_differences
• Risk assessment: medium
• Summary: The PR patch implements the same core security fix as upstream in lib/ssh/src/ssh_sftpd.erl: it restricts pending-buffer reprocessing to normal channel data (Type = 0) and adds a fallback clause to ignore extended data, which prevents the infinite loop described by the CVE. The main difference is that the PR omits the upstream test-suite changes, including the new regression test and an unrelated-looking test fixture preparation adjustment. The source-code fix itself appears functionally equivalent, with line offsets and blob IDs consistent with a backport to a different tree revision.
• Missing hunks:
  • All upstream changes to lib/ssh/test/ssh_sftpd_SUITE.erl are omitted, including registration of extended_data_no_infinite_loop/1 in exports and all(), the regression test body that sends extended data then verifies normal SFTP init still succeeds, and the prep/1 test file handling change.

Detailed analysis

1. Core fix equivalence: Yes, the substantive security fix is functionally equivalent. Upstream changes handle_data(Type, ChannelId, Data0, State = #state{pending = Pending}) -> to handle_data(0, ChannelId, Data0, State = #state{pending = Pending}) ->, and similarly changes the recursive call from handle_data(Type, ChannelId, Data, ...) to handle_data(0, ChannelId, Data, ...). It then adds a catch-all clause handle_data(_Type, _ChannelId, _Data, State) -> {ok, State}. with a comment stating extended data is ignored. The PR contains those exact logic changes. This addresses the bug mechanism: previously nonzero channel data types with pending buffered data could be recursively reprocessed without consuming the extended-data condition, causing an infinite loop; after the patch, only normal data goes through the pending-data parsing path, while extended data is discarded.

2. Differences vs upstream: The PR is packaged as a downstream patch file under SPECS/erlang/CVE-2026-54886.patch, includes Azure-specific metadata (Signed-off-by, Upstream-reference), and applies only the ssh_sftpd.erl hunk. It does not include any of the upstream test-suite modifications. The changed source context starts at different line numbers (208/229 instead of 235/256) and different blob IDs, which is normal for a backport against an older or diverged source snapshot. No additional code behavior changes beyond the upstream fix are present in the source hunk.

3. Missing hunks justification: The omitted hunks are test-only. The new test extended_data_no_infinite_loop/1 is directly relevant as a regression test for this CVE, while the prep/1 adjustment appears to be a test environment/fixture compatibility change needed in the upstream test tree. If Azure Linux packaging does not carry or run the upstream OTP test suite in this form, omission can be understandable. However, from a patch-equivalence perspective, these hunks are still missing relative to upstream. Their absence does not make the runtime fix wrong, but it reduces confidence because the regression is no longer covered in-tree.

4. Risk of incompleteness/regression: Runtime-fix risk is low to moderate and mainly tied to lack of regression coverage rather than logic mismatch. The new fallback explicitly ignores all nonzero Type channel data, matching the upstream comment and intended behavior. Because the implementation mirrors upstream, risk of a security-fix gap is low. The main residual risk is that without the upstream regression test, future maintenance could reintroduce the issue unnoticed. There is also a small interoperability risk whenever extended data is ignored, but that is upstream-approved behavior and therefore not a downstream divergence.

5. Backport/context safety: The patch appears to be a safe backport. The context line after the fix differs (handle_op(?SSH_FXP_INIT, ...) upstream vs handle_op(Request, ReqId, <<?UINT32(HLen)... in the PR), indicating the surrounding file version is older or structurally different, but the targeted handle_data function logic is the same. The line-number shift and different preimage hashes do not suggest semantic drift in the patched area. Therefore the backport context changes appear safe.

---

Verdict

✅ APPROVED — All checks passed. Ready to merge.

[Kanishk-Bansal]

LGTM, Patch have been ported and matches upstream ref.

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