From: sashiko-bot@kernel.org
To: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
Cc: linux-serial@vger.kernel.org
Subject: Re: [PATCH 2/3] serial: core: replace get_zeroed_page() with kzalloc()
Date: Sun, 30 Aug 2026 08:00:54 +0000 [thread overview]
Message-ID: <20260830080055.1BDF41F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260830-tty-v1-2-0cbe6170649b@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The transition from `get_zeroed_page(GFP_KERNEL)` to `kzalloc(PAGE_SIZE, GFP_KERNEL)` for allocating the serial port transmit buffer (`tport->xmit_buf`) breaks the strict page-alignment guarantee. Several serial drivers inherently rely on this buffer being page-aligned. `atmel_serial` explicitly panics via `BUG_ON(!PAGE_ALIGNED(tport->xmit_buf))`, and `pch_uart` corrupts DMA scatterlist addresses by masking out the lower bits (`sg_dma_address(sg) & ~(UART_XMIT_SIZE - 1)`) assuming the base address is page-aligned. If `kzalloc` returns an unaligned address (e.g., when SLUB debugging adds redzones), this results in DMA reading adjacent out-of-bounds kernel memory and transmitting it over the serial line.
--
commit 56b6291d1a96458932c4b0e5de37ae0df9e37c2d
Author: Mike Rapoport (Microsoft) <rppt@kernel.org>
serial: core: replace get_zeroed_page() with kzalloc()
This commit replaces the page allocator with kzalloc() for the serial port
transmit buffer. It aims to simplify the API and remove casts, noting that
performance differences are negligible.
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 95774b0f1484b..f12ce7d190fe6 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -247,29 +247,29 @@ static int uart_alloc_xmit_buf(struct tty_port *port)
> struct uart_state *state = container_of(port, struct uart_state, port);
> struct uart_port *uport;
> unsigned long flags;
> - unsigned long page;
> + unsigned char *buf;
>
> /*
> * Initialise and allocate the transmit and temporary
> * buffer.
> */
> - page = get_zeroed_page(GFP_KERNEL);
> - if (!page)
> + buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
[Severity: Critical]
Does replacing get_zeroed_page() with kzalloc() break page alignment
requirements for the transmit buffer?
Several serial drivers appear to rely on the transmit buffer being strictly
page-aligned. For example, in drivers/tty/serial/atmel_serial.c,
atmel_prepare_tx_dma() explicitly checks for this:
BUG_ON(!PAGE_ALIGNED(tport->xmit_buf));
Additionally, in drivers/tty/serial/pch_uart.c, dma_handle_tx() masks out
the lower bits of the DMA address, assuming the base is page-aligned:
sg_dma_address(sg) = (sg_dma_address(sg) &
~(UART_XMIT_SIZE - 1)) + sg->offset;
If kzalloc() returns an unaligned address (which can happen when SLUB
debugging adds redzones), could this result in a kernel panic in atmel_serial
or corrupted DMA scatterlist addresses in pch_uart?
Could this DMA corruption lead to out-of-bounds kernel memory being read
and transmitted over the serial line?
> + if (!buf)
> return -ENOMEM;
>
> uport = uart_port_ref_lock(state, &flags);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260830-tty-v1-0-0cbe6170649b@kernel.org?part=2
next prev parent reply other threads:[~2026-08-30 8:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-30 7:49 [PATCH 0/3] tty: replace page allocator calls with k[mz]alloc() Mike Rapoport (Microsoft)
2026-08-30 7:49 ` [PATCH 1/3] tty: port: replace get_zeroed_page() with kzalloc() Mike Rapoport (Microsoft)
2026-08-30 8:07 ` sashiko-bot
2026-08-30 7:49 ` [PATCH 2/3] serial: core: " Mike Rapoport (Microsoft)
2026-08-30 8:00 ` sashiko-bot [this message]
2026-08-30 8:44 ` Mike Rapoport
2026-08-31 3:02 ` Jiri Slaby
2026-08-31 8:28 ` Mike Rapoport
2026-08-30 7:49 ` [PATCH 3/3] tty: hvcs: replace __get_free_page() with kmalloc() Mike Rapoport (Microsoft)
2026-08-30 8:05 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260830080055.1BDF41F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=rppt@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox