RTEMS | Review all uart/console driver set_attributes() for B0 handling (#5558)
SHIVAM DEOLANKAR (@D3athSkulll)
gitlab at rtems.org
Sat Apr 25 04:18:01 UTC 2026
SHIVAM DEOLANKAR commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5558#note_149044
Inspected bsps/arm/ the **imxrt** , **efm32gg11**, **atsam , csb337 , csb336, stm32h7,** **stm32u5** driver needs a fix, rest 2 drivers seemed fine.
On reviewing console.c for arm/imxrt . Initially, the driver appeared safe as it delegates baud handling to the HAL. However, `LPUART_Init()` in `imxrt/mcux-sdk/drivers/lpuart/fsl_lpuart.c `performs division using the baud rate and only guards it with an assertion. Since assertions may be disabled, passing baud rate 0 can lead to divide-by-zero. Needs explicit check to reject baud rate 0 before calling the HAL.
On reviewing console.c for **arm/efm32gg11.** The function passes baud directly to `attribs_init()`, where it is used in a division (`/ baud`) without validation. If baud is 0, this results in a divide-by-zero. Needs explicit guard to reject baud rate 0 before calling `attribs_init()`.
Reviewed console.c for **arm/atsam**. It suffers from same issue. There is no guard and it performs division without any check. Needs explicit guard to reject baud rate 0.
Reviewed usart.c for **arm/csb337 .** Although a fallback baud is used when `B0` is provided, there is no guarantee the resulting baud is non-zero. The value is used in a division (`/ baud`) without validation, which may lead to divide-by-zero. Needs explicit guard after conversion.
Reviewed uart.c for **arm/csb336** . The function passes baud directly to `imx_uart_set_baud()`, where it is used in a division (`ref_freq / baud`) without validation. If baud is 0, this leads to a divide-by-zero. Added explicit guard to reject baud rate 0.
Reviewed console.c for **arm/stm32h7**. The function passes baud rate directly to `UART_SetConfig()`, which internally computes hardware parameters. Since baud rate 0 is not validated and may lead to divide-by-zero inside the HAL, this is solved by an explicit guard to reject baud rate 0 before calling the HAL.
Reviewing console.c for **arm/stm32u5.** The function passes baud rate directly to `UART_SetConfig()`, which internally computes hardware parameters. Since baud rate 0 is not validated and may lead to divide-by-zero inside the HAL, This also requires an explicit guard to reject baud rate 0 before calling the HAL.
\___________________________________________________________________________________\_
On reviewing console-config.c for **arm/imx.** Baud-dependent calculations are guarded with `if (baud != 0)`, ensuring no divide-by-zero occurs. B0 is safely ignored. No changes required.
On reviewing hsu.c for **arm/lpc32xx.** No changes required since the case is handled like imx.
--
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5558#note_149044
You're receiving this email because of your account on gitlab.rtems.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260425/8740d6dd/attachment.htm>
More information about the bugs
mailing list