Re: [PATCH v7 0/2] serial: core: fix baud rate fallback loop and baud_base overflow
From: Greg Kroah-Hartman
Date: Thu Oct 01 2026 - 05:09:23 EST
On Wed, Sep 30, 2026 at 12:58:59PM +0000, Hui Peng wrote:
> This series addresses two issues in serial core:
> 1. Division-by-zero WARN/Oops during baud rate fallback in uart_get_baud_rate().
> 2. 32-bit unsigned overflow in uart_set_info() when multiplying new_info->baud_base by 16.
>
> Note on v6 1/3:
> Patch 1/3 from v6 ("serial: 8250: fix deadlock in serial8250_register_ports")
> has been dropped. The hash_mutex race condition was originally found and
> reproduced on Linux 6.18.14 (where guard(mutex)(&hash_mutex) was dropped
> inside serial_get_or_create_irq_info() before serial_link_irq_chain() linked
> the port). We did not realize that it was already fixed in mainline by
> commit b339809edda1 ("serial: 8250: use guard()s"), which refactored to
> serial_get_or_create_irq_info_locked() with guard(mutex)(&hash_mutex) moved
> into serial_link_irq_chain(). Apologies for the noise in v6 1/3.
>
> All remaining patches are ported to the latest tip of mainline (551c722f4080)
> and dynamically verified in QEMU KVM with CONFIG_KASAN=y.
>
> Changes in v7:
> - Dropped patch 1/3 (already resolved in mainline).
> - Clarified in cover letter that 1/3 was found and reproduced on 6.18.14 and
> we did not realize it was already fixed in mainline.
> - Retained patch 1/2 and patch 2/2 using check_mul_overflow() as requested
> by Jiri Slaby.
>
> Hui Peng (2):
> serial: core: fix baud rate fallback in uart_get_baud_rate()
> serial: core: reject baud_base values that overflow port->uartclk in
> uart_set_info()
>
> drivers/tty/serial/serial_core.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
> --
> 2.47.3
You have sent 3 versions of this series in one day. Please relax and
slow down. I've now deleted all of these patches from my review queue.
Please wait a few days, take the time to make sure the submission is
correct, and then send a new version. Don't overwhelm reviewers without
helping them with review of other submissions, to do otherwise is not
very kind.
thanks,
greg k-h