There are 3 open security issues in bookworm.
3 issues left for the package maintainer to handle:
- CVE-2024-6563:
(needs triaging)
Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') vulnerability in Renesas arm-trusted-firmware allows Local Execution of Code. This vulnerability is associated with program files https://github.Com/renesas-rcar/arm-trusted-firmware/blob/rcar_gen3_v2.5/drivers/renesas/common/io/i... https://github.Com/renesas-rcar/arm-trusted-firmware/blob/rcar_gen3_v2.5/drivers/renesas/common/io/io_rcar.C . In line 313 "addr_loaded_cnt" is checked not to be "CHECK_IMAGE_AREA_CNT" (5) or larger, this check does not halt the function. Immediately after (line 317) there will be an overflow in the buffer and the value of "dst" will be written to the area immediately after the buffer, which is "addr_loaded_cnt". This will allow an attacker to freely control the value of "addr_loaded_cnt" and thus control the destination of the write immediately after (line 318). The write in line 318 will then be fully controlled by said attacker, with whichever address and whichever value ("len") they desire.
- CVE-2024-6564:
(needs triaging)
Buffer overflow in "rcar_dev_init" due to using due to using untrusted data (rcar_image_number) as a loop counter before verifying it against RCAR_MAX_BL3X_IMAGE. This could lead to a full bypass of secure boot.
- CVE-2023-49100:
(needs triaging)
Trusted Firmware-A (TF-A) before 2.10 has a potential read out-of-bounds in the SDEI service. The input parameter passed in register x1 is not validated well enough in the function sdei_interrupt_bind. The parameter is passed to a call to plat_ic_get_interrupt_type. It can be any arbitrary value passing checks in the function plat_ic_is_sgi. A compromised Normal World (Linux kernel) can enable a root-privileged attacker to issue arbitrary SMC calls. Using this primitive, he can control the content of registers x0 through x6, which are used to send parameters to TF-A. Out-of-bounds addresses can be read in the context of TF-A (EL3). Because the read value is never returned to non-secure memory or in registers, no leak is possible. An attacker can still crash TF-A, however.
You can find information about how to handle these issues in the security team's documentation.
![[bug history graph]](https://qa.debian.org/data/bts/graphs/a/arm-trusted-firmware.png){kind=link}