Fwd: Fwd: SySS Responsible Disclosure Policy
Robin Trost
Robin.Trost at syss.de
Fri Jun 26 12:03:22 CEST 2026
Hi Tom,
any updates on this issue?
Kind regards,
Robin
-------- Forwarded Message --------
Subject: Fwd: SySS Responsible Disclosure Policy
Date: Fri, 12 Jun 2026 22:47:14 +0200
From: Robin Trost <Robin.Trost at syss.de>
To: Tom Rini <trini at konsulko.com>
CC: u-boot at lists.denx.de
Hi Tom,
for the advisory (SYSS-2026-039: Arbitrary OOB Heap Write / Integer
Underflow during RSA Public Key Parsing) only you showed up as a
maintainer ("THE REST"). Therefore I've resend you the advisory.
As my last mail was already flaged by your mail provider, I've included
only the advisory (including a PoC and a "optional" fix). If necessary,
I can provide you a reproducer script, which illustrates arbitrary code
execution in the sandbox (including a python script which can be used to
build a malicious RSA public key).
If you have furhter questions, just let me know.
Kind regards,
Robin
-------- Forwarded Message --------
Subject: SySS Responsible Disclosure Policy
Date: Wed, 10 Jun 2026 15:46:26 +0200
From: Robin Trost <Robin.Trost at syss.de>
To: u-boot at lists.denx.de <u-boot at lists.denx.de>
CC: trini at konsulko.com <trini at konsulko.com>, p_mailqueue_disclosure
<disclosure at syss.de>
Hi all,
The SySS GmbH deals with security issues in a responsible way. In the
form of a security advisory we report security vulnerabilities which are
not in products of our customers and which are not excluded from public
disclosure due to contractual agreements with vendors.
The attached security advisories contain detailed information about the
found vulnerabilities that allows the vendor to reproduce and further
investigate the reported security issue. Vulnerabilities will be
disclosed to the public if a solution was published by the vendor or 45
days after the initial report by the SySS GmbH, regardless of the
vulnerability status, for example if there is a patch or workaround from
the affected vendor. In well-founded exceptional cases, this standard
procedure may not be followed and an alternative, adjusted publication
schedule will be negotiated with the vendor.
The goal of our Responsible Disclosure Policy is, to weigh up the need
of the public to know of security vulnerabilities against the vendor’s
time to remedy all security issues effectively. The final publication
schedule will be based on the best interests of the community overall,
considering both positions. Before the responsible disclosure of a
security vulnerability, the SySS GmbH allows vendors the opportunity to
analyze reported security issues, to develop effective countermeasures,
and to test them thoroughly.
If there are any further questions regarding the identified
vulnerabilities do not hesitate to contact me.
Kind regards,
--
Robin Trost
Senior IT-Security Consultant
______________________________________________________________
SySS GmbH
Schaffhausenstraße 77, 72072 Tübingen, Germany
Tel: +49 (0)7071 - 40 78 56-6169
Mobil: +49 (0)151 - 42209330
E-Mail: Robin.Trost at syss.de
Conf. Calls: https://syss.zoom.us/my/robin.trost
Web: https://syss.de
PGP-Fingerprint: 85FE 80E2 04F3 6177 C61A 4618 61DE F14F 698E 6EB3
Geschäftsführer: Sebastian Schreiber
Registergericht: Amtsgericht Stuttgart / HRB 382420
Steuernummer: 86118 / 55809
-------------- next part --------------
Advisory ID: SYSS-2026-039
Product: Das U-Boot ("the universal boot loader")
Manufacturer: DENX Software Engineering / U-Boot project
Affected Version(s): all versions up to and including master
at commit 987907ae4bcc (v2026.07-rc3-00008)
Tested Version(s): master at 987907ae4bcc
Vulnerability Type: Out-of-bounds Write (CWE-787),
Integer Underflow (CWE-191)
Risk Level: Medium
Solution Status: Open
Manufacturer Notification: 2026-06-10
Solution Date: (pending)
Public Disclosure: (pending)
CVE Reference: Not yet assigned
Author of Advisory: Robin Trost, SySS GmbH
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Overview:
Das U-Boot is a widely deployed open-source bootloader for embedded
devices.
The manufacturer describes the product as follows (see [1]):
"Das U-Boot, often shortened to U-Boot, is a free, open-source and
extensible boot loader available for many architectures (ARM, MIPS,
PowerPC, RISC-V, x86, x86_64), whose purpose is to perform various
hardware initialization tasks and boot the device's operating system
kernel."
Due to a missing bounds check in the RSA public-key processing code,
a crafted DER-encoded RSA public key with an oversized public exponent
can make U-Boot copy attacker-controlled bytes before an 8-byte heap
allocation.
In affected builds, this can be reached whenever an RSA public key is
processed via rsa_verify_with_pkey(), for example from
IMAGE_PRE_LOAD_SIG configuration or from certificate parsing paths that
select this backend.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vulnerability Details:
The function rsa_gen_key_prop() in lib/rsa/rsa-keyprop.c parses a DER
RSA public key and converts the parsed modulus and public exponent
into a struct key_prop used by U-Boot's RSA verifier.
The public exponent is copied into an 8-byte heap allocation:
/* lib/rsa/rsa-keyprop.c, rsa_gen_key_prop() */
(*prop)->public_exponent = calloc(1, sizeof(uint64_t));
if (!(*prop)->public_exponent) {
ret = -ENOMEM;
goto out;
}
memcpy((void *)(*prop)->public_exponent + sizeof(uint64_t)
- rsa_key.e_sz,
rsa_key.e, rsa_key.e_sz);
(*prop)->exp_len = sizeof(uint64_t);
The expression "sizeof(uint64_t) - rsa_key.e_sz" is only valid if
rsa_key.e_sz is at most eight bytes. If an attacker supplies an RSA
public key whose public-exponent INTEGER is longer than eight bytes,
the unsigned pointer offset underflows. The following memcpy() then
writes attacker-controlled public-exponent bytes before the allocated
8-byte destination buffer.
For the verified PoC, rsa_key.e_sz is 320 bytes. The write therefore
starts at:
public_exponent + 8 - 320 = public_exponent - 312
and writes 320 attacker-controlled bytes over adjacent heap memory.
U-Boot contains two RSA public-key parser implementations relevant to
this code path:
- lib/crypto/rsa_helper.c
- lib/mbedtls/rsa_helper.c
Neither parser bounds the parsed public-exponent size against the
8-byte destination buffer in rsa_gen_key_prop(). The MbedTLS-based
parser verifies general RSA public-key properties, such as E being
odd and E < N, but it still accepts a well-formed oversized public
exponent.
Exploiting the vulnerability allows an attacker to execute arbitrary
code. This might be abused to bypass a verified boot mechanism (e.g.
secure boot).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Proof of Concept (PoC):
In the verified sandbox build, the out-of-bounds write is used to
forge dlmalloc chunk metadata directly before the public_exponent
allocation. When rsa_free_key_prop() later calls free() on this
pointer, dlmalloc performs backward consolidation and unlinks the
attacker-forged previous chunk. This gives an attacker-controlled
write primitive.
In the stock bootm/image-pre-load PoC, this write primitive overwrites
the stack field:
&info->sig_info.crypto
with the address of a fake struct crypto_algo embedded in the
attacker-controlled DER bytes. The first image-pre-load header
signature check returns normally. The second image signature check
then dispatches through the corrupted crypto-algorithm pointer:
/* boot/image-pre-load.c, image_pre_load_sig_check_img_sig() */
ret = info->sig_info.crypto->verify(&info->sig_info, ®, 1,
sig, sig_len);
The fake crypto_algo object's verify function pointer is set to the
attacker-selected address 0x41414141, resulting in control of the
program counter.
The PoC was executed against a fresh U-Boot sandbox build at commit
987907ae4bcc with ASLR disabled via setarch -R. The build was
configured with:
CONFIG_ASAN=y
CONFIG_IMAGE_PRE_LOAD=y
CONFIG_IMAGE_PRE_LOAD_SIG=y
CONFIG_CMD_BOOTM_PRE_LOAD=y
CONFIG_RSA_VERIFY_WITH_PKEY=y
CONFIG_UNIT_TEST=n
The reproducer builds a structurally valid image-pre-load payload with
two RSA-3072 signatures:
- a signature over the 64-byte pre-load header
- a signature over the image body
The malicious RSA public key is placed in the stock image-pre-load
control devicetree property:
/image/pre-load/sig/public-key
The key is a DER-encoded RSAPublicKey with a 384-byte modulus and a
320-byte public exponent. The last eight public-exponent bytes encode
the ordinary RSA exponent 65537:
00 00 00 00 00 01 00 01
This makes the first RSA verification succeed after the vulnerable
copy has corrupted memory. U-Boot then reaches the second stock
verification call, which uses the corrupted crypto pointer.
The stock command used by the reproducer is:
host load hostfs - 0x1000000 /tmp/crypto_h1_bootm_preload/preload_image.bin;
bootm preload 0x1000000
The validated run recorded the following exploit metadata:
attacker_pc = 0x41414141
public_exponent heap pointer = 0x18d613c0
&info->sig_info.crypto = 0x7bfff52d59d8
public-key DER address = 0x18d170a8
fake crypto_algo address = 0x18d17274
crypto_algo.verify offset = 0x20
Observed ASan output:
886 bytes read in 0 ms
AddressSanitizer:DEADLYSIGNAL
=================================================================
==138466==ERROR: AddressSanitizer: SEGV on unknown address
0x000041414141 (pc 0x000041414141 bp 0x000011400340
sp 0x7fffffffc808 T0)
==138466==The signal is caused by a READ memory access.
AddressSanitizer:DEADLYSIGNAL
AddressSanitizer: nested bug in the same thread, aborting.
Observed GDB output:
Program received signal SIGSEGV, Segmentation fault.
0x0000000041414141 in ?? ()
PC=0x41414141
#0 0x0000000041414141 in ?? ()
#1 0x00005555556f25d1 in image_pre_load_sig_check_img_sig
(info=0x7bfff52d5970, addr=<optimized out>)
at boot/image-pre-load.c:350
#2 image_pre_load_sig (addr=<optimized out>)
at boot/image-pre-load.c:398
#3 image_pre_load (addr=<optimized out>)
at boot/image-pre-load.c:423
#4 bootm_pre_load (addr_str=<optimized out>)
at boot/bootm.c:283
This demonstrates that a stock bootm/image-pre-load verification path
can reach an attacker-selected instruction pointer through the
malicious RSA public key.
In a production deployment, the sink can be reached via
rsa_verify_with_pkey() which calls rsa_gen_key_prop().
In-tree paths that can process RSA public keys
through this function include IMAGE_PRE_LOAD_SIG and, depending on the
selected public-key backend and board configuration, PKCS#7/X.509
verification paths used by EFI Authenticode and capsule-update.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Solution:
One solution to fix the issue is to reject RSA public keys whose parsed
public exponent is larger than the destination buffer before performing
the copy in rsa_gen_key_prop():
--- a/lib/rsa/rsa-keyprop.c
+++ b/lib/rsa/rsa-keyprop.c
@@ -686,6 +686,11 @@ int rsa_gen_key_prop(const void *key, uint32_t keylen,
goto out;
}
+ if (rsa_key.e_sz > sizeof(uint64_t)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
memcpy((void *)(*prop)->public_exponent + sizeof(uint64_t)
- rsa_key.e_sz,
rsa_key.e, rsa_key.e_sz);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disclosure Timeline:
2026-06-01: Vulnerability discovered
20YY-06-10: Vulnerability reported to manufacturer
20YY-XX:XX: Patch released by manufacturer
20YY-XX-XX: Public disclosure of vulnerability
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
References:
[1] Product website for "Das U-Boot"
https://u-boot.org/
[2] SySS Security Advisory SYSS-2026-039
https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2026-039.txt
[3] SySS Responsible Disclosure Policy
https://www.syss.de/en/responsible-disclosure-policy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Credits:
This security vulnerability was found by Robin Trost of SySS
GmbH.
E-Mail: robin.trost at syss.de
Public Key: https://www.syss.de/fileadmin/dokumente/PGPKeys/Robin_Trost.asc
Key ID: 0x698E6EB3
Key Fingerprint: 85FE 80E2 04F3 6177 C61A 4618 61DE F14F 698E 6EB3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disclaimer:
The information provided in this security advisory is provided "as is"
and without warranty of any kind. Details of this security advisory may
be updated in order to provide as accurate information as possible. The
latest version of this security advisory is available on the SySS website.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Copyright:
Creative Commons - Attribution (by) - Version 4.0
URL: https://creativecommons.org/licenses/by/4.0/deed.en
More information about the U-Boot
mailing list