Hello all,
I know that v2.28.10 is EOL, but I've been working on bringing security bug fixes to our distribution of it as part of my work in shoring up the Julia package ecosystem. I've largely leaned on the Debian security team's work thus far; they have the much harder task of supporting 2.16.9 for bullseye (security) and have done great work in bringing that version up to date through CVE-2025-52497. I've re-landed their backport patches against v2.28.10; these can be found on our build tree [1] or my fork [2]:
1. https://github.com/JuliaPackaging/Yggdrasil/tree/54c5a3e8e72899a3a778d8617fe...
2. https://github.com/Mbed-TLS/mbedtls/compare/v2.28.10...mbauman:mbedtls:v2.28...
Now I'm faced with the daunting prospect of last week's CVE-2025-54764 and CVE-2025-59438. These are *much* larger changesets. Has anyone else begun tackling this? I very much appreciated the guidance that’s included in the advisory itself, but I'm guessing there may be others in our situation... and I came here looking to see if anyone had begun talking about this (or working on it) yet.
Best, Matt
Hi Matt,
First, thank you very much for backporting security fixes. The maintenance team is aware that 3 years is quite short for a long-time support branch, but we simply don't have the resources to maintain many old branches.
For CVE-2025-59438 (PKCS7 padding decryption through PSA), I think you can easily cherry-pick the changes in the library, and run the existing tests to ensure that this doesn't break functionality. Backporting the tests to ensure that the new code is constant-time would be a lot harder.
For CVE-2025-54764 (RSA side channels), I think the only realistic path is to copy bignum_core.c and at least parts of bignum.c from 3.6, and then probably backport some related changes to rsa*.c. Our fix relies heavily on the groundwork that we had done in early 3.x versions in rewriting parts of bignum to be caller-allocating and constant-time.
You may consider skipping CVE-2025-54764, depending on your threat model. This patch defends against a timing attack that can recover secrets in a single trace. The code is also protected by randomized blinding, which defeats a large class of attacks that require many traces. Obtaining precise timing measurements in a single trace is easy in some environments, such as microcontrollers, or operating systems attacking a hypervisor or secure environment. It is a lot harder from user-mode software running on a PC/server-style CPU. That being said, attack techniques only ever get better, and published attack techniques tend to lag behind unpublished ones. So I am definitely not claiming that CVE-2025-54764 is irrelevant for a typical Linux or Windows environment.
Best of luck,
Thanks Gilles! I really appreciate the guidance. I've tried this a few different ways, but all roads seem to lead me down into the big constant-time refactor (https://github.com/Mbed-TLS/mbedtls/pull/7578), which gets highly entangled with a number of unrelated build system (ifdef) changes. I'll be putting this on my back-burner for the time-being, but will definitely be keeping tabs on other maintainers' work.
Best, Matt
On Mon, Oct 27, 2025 at 11:48 AM Gilles Peskine gilles.peskine@arm.com wrote:
Hi Matt,
First, thank you very much for backporting security fixes. The maintenance team is aware that 3 years is quite short for a long-time support branch, but we simply don't have the resources to maintain many old branches.
For CVE-2025-59438 (PKCS7 padding decryption through PSA), I think you can easily cherry-pick the changes in the library, and run the existing tests to ensure that this doesn't break functionality. Backporting the tests to ensure that the new code is constant-time would be a lot harder.
For CVE-2025-54764 (RSA side channels), I think the only realistic path is to copy bignum_core.c and at least parts of bignum.c from 3.6, and then probably backport some related changes to rsa*.c. Our fix relies heavily on the groundwork that we had done in early 3.x versions in rewriting parts of bignum to be caller-allocating and constant-time.
You may consider skipping CVE-2025-54764, depending on your threat model. This patch defends against a timing attack that can recover secrets in a single trace. The code is also protected by randomized blinding, which defeats a large class of attacks that require many traces. Obtaining precise timing measurements in a single trace is easy in some environments, such as microcontrollers, or operating systems attacking a hypervisor or secure environment. It is a lot harder from user-mode software running on a PC/server-style CPU. That being said, attack techniques only ever get better, and published attack techniques tend to lag behind unpublished ones. So I am definitely not claiming that CVE-2025-54764 is irrelevant for a typical Linux or Windows environment.
Best of luck,
-- Gilles Peskine TF-PSA-Crypto and Mbed TLS developer
On 27/10/2025 15:58, Matt Bauman via mbed-tls wrote:
Hello all,
I know that v2.28.10 is EOL, but I've been working on bringing security
bug fixes to our distribution of it as part of my work in shoring up the Julia package ecosystem. I've largely leaned on the Debian security team's work thus far; they have the much harder task of supporting 2.16.9 for bullseye (security) and have done great work in bringing that version up to date through CVE-2025-52497. I've re-landed their backport patches against v2.28.10; these can be found on our build tree [1] or my fork [2]:
https://github.com/JuliaPackaging/Yggdrasil/tree/54c5a3e8e72899a3a778d8617fe...
https://github.com/Mbed-TLS/mbedtls/compare/v2.28.10...mbauman:mbedtls:v2.28...
Now I'm faced with the daunting prospect of last week's CVE-2025-54764
and CVE-2025-59438. These are *much* larger changesets. Has anyone else begun tackling this? I very much appreciated the guidance that’s included in the advisory itself, but I'm guessing there may be others in our situation... and I came here looking to see if anyone had begun talking about this (or working on it) yet.
Best, Matt
mbed-tls@lists.trustedfirmware.org
-
Gilles Peskine -
Matt Bauman