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]:
>
> 1. https://github.com/JuliaPackaging/Yggdrasil/tree/54c5a3e8e72899a3a778d8617fe4015ac6da20be/M/MbedTLS/MbedTLS%402.28.1010/bundled/patches
>
> 2. https://github.com/Mbed-TLS/mbedtls/compare/v2.28.10...mbauman:mbedtls:v2.28.10plus
>
> 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
>