Summary
I spotted a buffer overflow vulnerability at the following location in the Zephyr STM32 Crypto driver source code:
https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/crypto/crypto_stm32.c
Details
Buffer overflow due to ineffective assert check in /drivers/crypto/crypto_stm32.c:
static void copy_reverse_words(uint8_t *dst_buf, int dst_len,
uint8_t *src_buf, int src_len)
{
int i;
__ASSERT_NO_MSG(dst_len >= src_len); /* VULN: assert */
__ASSERT_NO_MSG((dst_len % 4) == 0);
memcpy(dst_buf, src_buf, src_len); /* VULN: buffer overflow */
for (i = 0; i < dst_len; i += sizeof(uint32_t)) {
sys_mem_swap(&dst_buf[i], sizeof(uint32_t));
}
}
The function copy_reverse_words() is called in a few locations that might be problematic, because src_len
might be attacker-controlled:
- crypto_stm32_ctr_encrypt()
- crypto_stm32_ctr_decrypt()
- crypto_stm32_session_setup()
PoC
I haven't tried to reproduce these potential vulnerabilities against a live install of the Zephyr OS.
Impact
If the unchecked length above is confirmed to be attacker-controlled and if input crosses a security boundary, the impact of the buffer overflow vulnerability could range from denial of service to arbitrary code execution.
Patches
main: #61839
Summary
I spotted a buffer overflow vulnerability at the following location in the Zephyr STM32 Crypto driver source code:
https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/crypto/crypto_stm32.c
Details
Buffer overflow due to ineffective assert check in /drivers/crypto/crypto_stm32.c:
The function copy_reverse_words() is called in a few locations that might be problematic, because
src_len
might be attacker-controlled:PoC
I haven't tried to reproduce these potential vulnerabilities against a live install of the Zephyr OS.
Impact
If the unchecked length above is confirmed to be attacker-controlled and if input crosses a security boundary, the impact of the buffer overflow vulnerability could range from denial of service to arbitrary code execution.
Patches
main: #61839