Merge changes from topic "mb/sec-advisories" into integration
* changes: docs(security): add security advisory for FIP TOC docs(security): add BL1 FWU DoS advisory details
This commit is contained in:
Olivier Deprez
TrustedFirmware Code Review
commit
cffef08ec3
@ -18,3 +18,5 @@ Security Advisories
|
||||
security-advisory-tfv-11.rst
|
||||
security-advisory-tfv-12.rst
|
||||
security-advisory-tfv-13.rst
|
||||
security-advisory-tfv-14.rst
|
||||
security-advisory-tfv-15.rst
|
||||
|
||||
70
docs/security_advisories/security-advisory-tfv-14.rst
Normal file
70
docs/security_advisories/security-advisory-tfv-14.rst
Normal file
@ -0,0 +1,70 @@
|
||||
Advisory TFV-14 (CVE-2026-34879)
|
||||
================================
|
||||
|
||||
+----------------+-----------------------------------------------------------------+
|
||||
| Title | BL1 FWU range-check mismatch in FWU_SMC_IMAGE_COPY can cause |
|
||||
| | out-of-range memory access. |
|
||||
+================+=================================================================+
|
||||
| CVE ID | `CVE-2026-34879`_ |
|
||||
+----------------+-----------------------------------------------------------------+
|
||||
| Date | Reported on 16 Jan 2026 |
|
||||
+----------------+-----------------------------------------------------------------+
|
||||
| Versions | TF-A releases with BL1 FWU mode enabled prior to the fixes |
|
||||
| Affected | in `48739`_ and `48740`_. |
|
||||
+----------------+-----------------------------------------------------------------+
|
||||
| Configurations | Platforms that enable BL1 FWU mode and expose |
|
||||
| Affected | FWU_SMC_IMAGE_COPY to the Normal World. |
|
||||
+----------------+-----------------------------------------------------------------+
|
||||
| Impact | Denial of Service (secure world data abort / reboot loop). |
|
||||
+----------------+-----------------------------------------------------------------+
|
||||
| Fix Version | `48739`_ "fix(bl1): harden FWU copy/auth overflow checks" |
|
||||
| | `48740`_ "fix(arm): harden FWU address range checks" |
|
||||
+----------------+-----------------------------------------------------------------+
|
||||
| Credit | Prasanth Sundararajan |
|
||||
| | https://www.linkedin.com/in/prasanthsundararajan/ |
|
||||
+----------------+-----------------------------------------------------------------+
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
In BL1 Firmware Update (FWU) mode, the FWU_SMC_IMAGE_COPY path validated
|
||||
image ranges using an overflow check based on (size - 1) but then consumed
|
||||
the full block size in subsequent range checks and memcpy operations. This
|
||||
created a mismatch where certain malformed requests could pass validation
|
||||
and later trigger a memcpy from an invalid or unmapped address.
|
||||
|
||||
A compromised Normal World component can issue a malformed FWU_SMC_IMAGE_COPY
|
||||
request while the device is in FWU mode, pass validation, and cause BL1 to
|
||||
attempt to copy from an invalid address. In testing, this results in a BL1
|
||||
data abort and can lead to a secure-side reboot loop (availability impact).
|
||||
|
||||
Exploitability Details
|
||||
----------------------
|
||||
|
||||
This issue is exploitable only when the device is running in BL1 FWU mode and
|
||||
the `FWU_SMC_IMAGE_COPY` interface is reachable from the Normal World. An
|
||||
attacker needs control of a Normal World component capable of issuing SMC calls
|
||||
in FWU mode (for example, a compromised bootloader, recovery image, or update
|
||||
agent). No secure-world code execution is required; the attack is performed
|
||||
entirely through crafted FWU requests.
|
||||
|
||||
The attacker submits a request with carefully chosen source address and size
|
||||
parameters that pass the legacy range validation but produce a different
|
||||
effective range when the copy occurs. Because the copy uses the full block size,
|
||||
BL1 attempts to read from an invalid or unmapped address, resulting in a
|
||||
secure-world data abort. In practice this yields a denial of service in FWU
|
||||
mode, often observed as a secure-side reboot loop.
|
||||
|
||||
Mitigation and Recommendations
|
||||
------------------------------
|
||||
|
||||
The issue is fixed by making overflow and range validation match the actual
|
||||
block size used by bl1_plat_mem_check() and memcpy(), and by validating
|
||||
end-exclusive ranges computed safely from (base + size).
|
||||
|
||||
Users should apply the fixes in the commits referenced below and ensure that
|
||||
all TF-A builds enabling BL1 FWU mode include these changes.
|
||||
|
||||
.. _CVE-2026-34879: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-34879
|
||||
.. _48739: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/48739
|
||||
.. _48740: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/48740
|
||||
80
docs/security_advisories/security-advisory-tfv-15.rst
Normal file
80
docs/security_advisories/security-advisory-tfv-15.rst
Normal file
@ -0,0 +1,80 @@
|
||||
Advisory TFV-15 (CVE-2026-34878)
|
||||
================================
|
||||
|
||||
+----------------+-----------------------------------------------------------------+
|
||||
| Title | Insufficient validation of FIP ToC offsets in BL1/BL2 can cause |
|
||||
| | unintended reads and secure memory disclosure at boot. |
|
||||
+================+=================================================================+
|
||||
| CVE ID | `CVE-2026-34878`_ |
|
||||
+----------------+-----------------------------------------------------------------+
|
||||
| Date | Reported on 22 Jan 2026 |
|
||||
+----------------+-----------------------------------------------------------------+
|
||||
| Versions | TF-A releases prior to the fixes in `48351`_, `49485`_. |
|
||||
| Affected | |
|
||||
+----------------+-----------------------------------------------------------------+
|
||||
| Configurations | Platforms that load BL1/BL2 from a FIP and allow firmware |
|
||||
| Affected | update or boot from a modified FIP. |
|
||||
+----------------+-----------------------------------------------------------------+
|
||||
| Impact | Secure memory disclosure during boot and potential DoS |
|
||||
| | (boot halts on failed authentication). |
|
||||
+----------------+-----------------------------------------------------------------+
|
||||
| Fix Version | `48351`_ "fix(io): validate FIP ToC bounds and catch short |
|
||||
| | reads" |
|
||||
| | `49485`_ "feat(lib): add u64 overflow helper" |
|
||||
| | checks" |
|
||||
+----------------+-----------------------------------------------------------------+
|
||||
| Credit | Kevin Chen |
|
||||
+----------------+-----------------------------------------------------------------+
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
Even when Trusted Boot is enabled, the FIP metadata (header and ToC) is not
|
||||
cryptographically signed by design and must be treated as untrusted input.
|
||||
BL1/BL2 parse the FIP ToC to locate images, calculate offsets and lengths, and
|
||||
perform reads and copies before authentication is performed. The existing
|
||||
logic did not sufficiently validate FIP metadata fields (including ToC
|
||||
offsets, sizes, and read lengths) and did not consistently detect short reads.
|
||||
A crafted or corrupted FIP can therefore cause BL1/BL2 to read and copy
|
||||
unintended data-including secure memory mapped into the EL3 translation
|
||||
regime-into non-secure memory regions, potentially disclosing sensitive
|
||||
contents.
|
||||
|
||||
This issue affects boot-time images only (BL1/BL2), not runtime firmware
|
||||
(BL31). The exposure exists only during early boot while BL1/BL2 are parsing
|
||||
the FIP and copying images; once authentication fails, boot halts. In most
|
||||
deployments, useful secrets are not resident in memory during that early
|
||||
boot interval. In configurations where TF-A decrypts confidential images into
|
||||
Trusted SRAM, the disclosure can expose plaintext at boot. Note that BL33 is
|
||||
typically loaded into non-secure memory, so not all image copies target secure
|
||||
buffers during authentication. In practice, the same malformed metadata
|
||||
typically leads to authentication failure and halts the boot process,
|
||||
resulting in a DoS.
|
||||
|
||||
Exploitability Details
|
||||
----------------------
|
||||
|
||||
An attacker must be able to supply or modify the FIP that BL1/BL2 will parse,
|
||||
for example via a firmware update mechanism, removable storage, or a system
|
||||
configuration that allows boot from an untrusted FIP source. Because the FIP
|
||||
metadata is unsigned, Trusted Boot does not protect the ToC from tampering.
|
||||
By crafting offsets and sizes that point outside the actual FIP payload, or
|
||||
that trigger integer overflow, the attacker can force BL1/BL2 to issue reads
|
||||
that extend beyond the FIP and into adjacent regions mapped in secure address
|
||||
space. The incorrect or short reads can then be copied into the destination
|
||||
buffers for authentication, which fails, halting the boot process.
|
||||
|
||||
Mitigation and Recommendations
|
||||
------------------------------
|
||||
|
||||
Apply the fixes referenced below. They add strict bounds checks, overflow-safe
|
||||
validation, and short-read detection for FIP metadata parsing and associated
|
||||
copy operations.
|
||||
|
||||
Where feasible, reduce exposure by ensuring the FIP is stored in a protected
|
||||
location and by restricting or disabling boot paths that accept externally
|
||||
modifiable FIP images.
|
||||
|
||||
.. _CVE-2026-34878: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-34878
|
||||
.. _48351: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/48351
|
||||
.. _49485: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/49485
|
||||
Loading…
x
Reference in New Issue
Block a user