Re: [PATCH v3 1/2] serial: core: Unify uart_get_baud_rate() success return paths

[Maciej W. Rozycki]

On Tue, 3 Nov 2026, sashiko-bot@xxxxxxxxxx wrote:

> [Severity: High]
> Can this break B0 hangup and trigger a division by zero when max is less
> than max(min, 9600)?
> 
> Commit 091ea8e5d34e ("serial: core: prevent division by zero by always
> returning non-zero baud rate") removed the hung_up guard from the
> out-of-range fallback path in uart_get_baud_rate() because baud == 0
> returned max(min, 9600) immediately before reaching the range check. With
> this change, B0 is subject to the baud <= max check, and if that fails it
> falls through into the termios-mutating fallback path:

 I maintain that unifying the success return paths does have a value and 
instead the failure path needs to be corrected as per 
<https://lore.kernel.org/r/20261020184131.2893575-4-hugo@xxxxxxxxxxx/> 
outstanding (thanks, Hugo, for sending the ping for the series I've meant 
to refer anyway, it made it easier for me to find it).

> Several in-tree callers can pass max < max(min, 9600) to
> uart_get_baud_rate():

 Well, if that is indeed the case (I thought 134.5bps times are long gone 
and everyone does at least 9600bps nowadays), then shouldn't the (fallback 
as from 2/2 in this series) B0 rate be min(max(min, 9600), max) instead?

 It's not in the hot path, so I think we ought to do this clipping anyway, 
for safety.

> Note that the follow-up commit "serial: core: Don't clobber the baud rate
> on hangup via B0" changes the B0 assignment to:
> 
> 	baud = port->hup_speed ? port->hup_speed : max(min, 9600);
> 
> which still fails the baud <= max check whenever port->hup_speed is 0

 Well, this is obviously rubbish.

> (such as before any valid speed has been saved, or when max == 0) or when
> port->hup_speed exceeds a reduced max.

 See the discussion above.

  Maciej