Repository navigation
CVE-2026-21895: prime-is-1 panic fix (#624) not on master #690
Description
Activity
The fix for the logic is there, however it looks like the regression test wasn't carried over and probably should be.
As it were, the entire implementation diverged as we moved from
num-biginttocrypto-bigint.Spun up the test in #692 per your suggestion — single-file change to
src/key.rs, no logic touch (the underlying fix invalidate_private_key_partsis already on master). The port required two small adaptations vs upstream2926c91bef's test:BigUint→BoxedUint, and routing throughfrom_components_with_large_exponent(under#[cfg(feature = "hazmat")], like the existing small/large-exponent tests) since master'sfrom_componentsnow enforces theMIN_PUB_EXPONENTbound that would reject the original test'se = 185before reaching the prime check. Happy to rework if you'd prefer a non-hazmat variant with realistic-size primes.
Heads-up — running a backport-gap scanner across NVD and noticed the fix attached to CVE-2026-21895 / GHSA does not appear on
masteryet.The upstream patch is 2926c91 — "fix: do not panic on a prime being 1 when loading a secret key (#624)" — which lands on a release branch / different lineage.
Against current
master:compare master...2926c91bef7creturnsstatus=diverged,behind_by=161,ahead_by=8. The 8 ahead commits include the panic-fix on the source side; nothing equivalent shows on master.repo:RustCrypto/RSA "do not panic on a prime being 1 when loading a secret key"→ 0 results in master's history.Cargo.toml,Cargo.lock,src/key.rsare all present onmasterand the panic-prone code path insrc/key.rsstill matches the pre-fix shape.If the master refactor obviated the bug a different way, please point me at the commit and I will close this. Otherwise a cherry-pick (or equivalent rewrite) of #624 onto master would resolve it.
I can open a draft PR if that is preferred over an issue — let me know.
— vulgraph backport scanner