[PATCH 0/5] serial: core: improve safety of uart_get_baud_rate()

[Hugo Villeneuve]

From: Hugo Villeneuve <hvilleneuve@xxxxxxxxxxxx>

serial: core: improve safety of uart_get_baud_rate()

Hello,
this patch series brings some improvements to uart_get_baud_rate() by
making it safer.

This originate from a review and discussions of a patch by Biju Das [1] to
fix a potential division by zero bug in the Renesas serial drivers
sh-sci and rsci.

First the comments in uart_get_baud_rate() are extremely outdated and no
longer match what the code does, which does not help when trying to fully
understand what the function does. One of the patch in this series updates
them.

All drivers, except apbuart and icom, call uart_get_baud_rate() and do not
check the returned baud rate, because it is assumed that it cannot return a
zero value. However, not all devices support a speed of 9600, and for these
uart_get_baud_rate() could return zero for the B0 case. This in turn
could trigger a "Division by zero in kernel" fault.

To be clear, this doesn't originate from a crash report, but from analyzing
the code during the above mentioned review. To test this potential bug, I
simply modified the "min" baud rate passed as argument to
uart_get_baud_rate() to 19200 for the sc16is7xx driver, and was able to
trigger the fault with "stty /dev/ttySC0 0" set to a zero baud rate
(hang up).

Historically, there was commit 16ae2a877bf4 ("serial: Fix crash if the minimum rate of the device is > 9600 baud")
in 2010 to try to prevent a zero value being returned, and added a warning
to that effect.

Then commit 23bf72faaebd ("serial: core: tidy invalid baudrate handling in uart_get_baud_rate")
in 2023 removed the warning:

  uart_get_baud_rate has input parameters 'min' and 'max' limiting the
  range of acceptable baud rates from the caller's perspective. If neither
  current or old termios structures have acceptable baud rate setting and
  9600 is not in the min/max range either the function returns 0 and
  issues a warning.
  However for a UART that does not support speed of 9600 baud this is
  expected behavior.
  Clarify that 0 can be (and always could be) returned from the
  uart_get_baud_rate. Don't issue a warning in that case.

To remove any ambiguity, and to make sure all drivers handle the returned
value the same, make sure uart_get_baud_rate() will always return a
non-zero value in all scenarios.

This ensures that for devices that do not support a speed of 9600, and B0
is the desired baud rate specified in termios, then the returned value will
be 9600 or the input parameters 'min', whichever is the greatest.

Tested on a custom board with a VAR-SOM-6UL SOM and a sc16is752 DUART.

Thank you.

Link [1] https://lore.kernel.org/all/20260408142105.310210-1-biju.das.jz@xxxxxxxxxxxxxx/raw

Hugo Villeneuve (5):
  serial: icom: remove check for zero baud rate from
    uart_get_baud_rate()
  serial: apbuart: remove check for zero baud rate from
    uart_get_baud_rate()
  serial: core: update uart_get_baud_rate() obsolete comments
  serial: core: simplify clipping logic in uart_get_baud_rate()
  serial: core: prevent division by zero by always returning non-zero
    baud rate

 drivers/tty/serial/apbuart.c     |  2 --
 drivers/tty/serial/icom.c        |  2 --
 drivers/tty/serial/serial_core.c | 34 ++++++++++++++------------------
 3 files changed, 15 insertions(+), 23 deletions(-)


base-commit: a1a81aef99e853dec84241d701fbf587d713eb5b
-- 
2.47.3