[AutoPR- Security] Patch keras for CVE-2026-12480 [MEDIUM]

[azurelinux-security]

Auto Patch keras for CVE-2026-12480.

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

Change Log

• CVE-2026-12480

Does this affect the toolchain?

YES/NO

Associated issues

• N/A

Links to CVEs

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

Test Methodology

• Pipeline build id: Buddy Build URL

[Ratiranjan5]

CVE-2026-12480:

1. The keras package version 3.3.3 falls within the affected range for CVE-2026-12480 (all versions prior to 3.12.2 / 3.14.1). The vulnerable code is present in keras-3.3.3.

2. Upstream patch (d5a88bdb) backported by AI.
   Below are the differences between the AI backport and upstream. The security fix is identical in both patches. Both add the check if dataset.is_virtual: raise ValueError(...) inside safe_get_h5_dataset() to reject virtual datasets.

• Our 3.3.3 has both H5IOStore and a helper class H5Entry, where H5Entry is the one that actually reads the HDF5 datasets. Upstream doesn't have H5Entry, that logic was folded into class H5IOStore. So, in the AI backport, the safe_get_h5_dataset check and the _verify_* removal go into H5Entry where the read happens in 3.3.3, while upstream applies the same fix in H5IOStore.

• In our 3.3.3, the function load_weights_from_hdf5_group takes (f, model) and has no skip_mismatch parameter, while upstream's version is (group, model, skip_mismatch=False). So the backport keeps the 3.3.3 signature instead of copying upstream's. Another function load_weights_from_hdf5_group_by_name matches in both (it already has skip_mismatch=False).

• file_editor.py is omitted. This file doesn't exist in Keras 3.3.3. The only change upstream made to it was swapping how h5py is imported, which has nothing to do with the security fix.

3. Patch applied cleanly.

4. Buddy Build passed on amd64 but failed on arm64, which is expected as the spec defines ExclusiveArch: x86_64.

[v-aaditya]

CVE-2026-12480:

1. The keras package version 3.3.3 falls within the affected range for CVE-2026-12480 (all versions prior to 3.12.2 / 3.14.1). The vulnerable code is present in keras-3.3.3.
2. Upstream patch (d5a88bdb) backported by AI.
   Below are the differences between the AI backport and upstream. The security fix is identical in both patches. Both add the check if dataset.is_virtual: raise ValueError(...) inside safe_get_h5_dataset() to reject virtual datasets.

• Our 3.3.3 has both H5IOStore and a helper class H5Entry, where H5Entry is the one that actually reads the HDF5 datasets. Upstream doesn't have H5Entry, that logic was folded into class H5IOStore. So, in the AI backport, the safe_get_h5_dataset check and the _verify_* removal go into H5Entry where the read happens in 3.3.3, while upstream applies the same fix in H5IOStore.
• In our 3.3.3, the function load_weights_from_hdf5_group takes (f, model) and has no skip_mismatch parameter, while upstream's version is (group, model, skip_mismatch=False). So the backport keeps the 3.3.3 signature instead of copying upstream's. Another function load_weights_from_hdf5_group_by_name matches in both (it already has skip_mismatch=False).
• file_editor.py is omitted. This file doesn't exist in Keras 3.3.3. The only change upstream made to it was swapping how h5py is imported, which has nothing to do with the security fix.

3. Patch applied cleanly.
4. Buddy Build passed on amd64 but failed on arm64, which is expected as the spec defines ExclusiveArch: x86_64.

@Ratiranjan5's analysis seems correct.
Although the AI patch was missing 1 hunk in src/legacy/saving/legacy_h5_format.py file from upstream patch. I have updated the patch.

Below is my brief analysis of CVE-2026-12480

1. After updating the patch now, the upstream changes in file src/legacy/saving/legacy_h5_format.py completely matches with the changes made in AI patch.
2. In keras version 3.3.3 the src/saving/file_editor.py file does not exist, therefore the changes are not included in the AI patch.
3. In keras version 3.3.3, the src/saving/saving_lib.py file has both H5IOStore and a leaf entry class H5Entry, which has the affected functions _verify_dataset. H5Entry class is the one that actually reads the HDF5 datasets and that logic is folded into class H5IOStore upstream. The AI patch has therefore been adapted to account for this structural difference from the upstream patch.
4. The AI patch has upstream patch reference.
5. Re-triggered the Buddy Build and it has passed except the "test built packages" phase on ARM64 has failed, which is expected as the spec defines ExclusiveArch: x86_64.

[mfrw]

LGTM ✅ — AI backport of the upstream keras H5-validation fix is faithful and complete on the supported arch; the only CI red is an unrelated aarch64 install-test infra flake for an ExclusiveArch: x86_64 package.

Patch fidelity — CVE-2026-12480.patch

AI Backport of upstream keras-team/keras@d5a88bd ("Refactor and share H5 validation code between legacy and new format", #22801). Verified hunk-by-hunk against the upstream .patch:

Area	Status
safe_get_h5_group / safe_get_h5_dataset (the actual fix)	✅ byte-for-byte identical to upstream — reject ExternalLink/SoftLink, and external/virtual datasets (the H5 link-traversal / arbitrary-read vector)
Guarded call sites	✅ every raw read (f["model_weights"], f["top_level_model_weights"], hdf5_group["optimizer_weights"], self.h5_file["vars"], self.group[name], …) converted to safe_get_*
Old weak helpers _verify_group / _verify_dataset	✅ definitions and all call sites removed — no orphaned references left behind
New imports in legacy_h5_format.py	✅ safe_get_h5_group / safe_get_h5_dataset imported from saving_lib
Base-version adaptation	✅ load_weights_from_hdf5_group(group, model) keeps the 3.3.3 base signature (no skip_mismatch); no caller passes it

Accounted-for deltas (all expected):

• 17 guard call-sites vs upstream's 20 — the 3-call difference is entirely in H5Entry, whose extra code paths exist only on upstream HEAD, not in the 3.3.3 base. Every H5 access present in the base is guarded.
• Line offsets / blob hashes differ (different base version) — expected.

Spec hygiene — keras.spec

• ✅ Release: 7 → 8, matches the %changelog top entry (3.3.3-8, Mon Jul 06 2026, Security Servicing Account, CVE-2026-12480).
• ✅ Patch7: CVE-2026-12480.patch declared sequentially (after Patch6) and applied via %autosetup -p1.
• ✅ No source tarball change → no *.signatures.json update needed (Source Signature Check green).
• ✅ No BuildRequires change needed (pure-Python patch, no parser/codegen).

Build / CI — buddy build 1154433

All 17 GitHub checks green. Timeline tally: 165 succeeded · 14 skipped · 4 failed. Note keras is ExclusiveArch: x86_64, so it only builds/matters on AMD64.

Stage	AMD64 (x86_64)	ARM64 (aarch64)
Build	✅ Built: keras-3.3.3-8.azl3.src.rpm → python3-keras-3.3.3-8.azl3.x86_64.rpm	⏭️ skipped — ExclusiveArch: x86_64 (srpmpacker: cannot be built on current architecture)
Install-test	✅ test_install_amd64 passed	❌ test_install_arm64 — infra, not keras (see below)
%check	N/A — spec has no %check section	N/A
Sodiff	N/A — pure-Python, no .so ABI surface	N/A
Postbuild (License/Guardian)	✅	✅

The 4 failures are all the single test_built_packages_arm64 stage. Log shows container/harness errors — Unable to find image 'mcr.microsoft.com/azurelinux/base/core:3.0', touch: cannot touch '/var/lib/rpm-state/systemd-resolved.initial-installation', Cannot kill container … is not running, Bash exited with code '1'. The harness's rpms_to_install also lists a python3-keras-…aarch64.rpm that never exists (x86_64-only package). No keras build/test breakage — the equivalent AMD64 install-test passed. Recommend re-triggering the flaky arm64 stage; not a blocker.

Signed-Off By: @mfrw