From: sashiko-bot@kernel.org
To: "Til Kaiser" <mail@tk154.de>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net v2 1/4] net: mvpp2: sync RX data at the hardware packet offset
Date: Wed, 03 Jun 2026 16:55:18 +0000 [thread overview]
Message-ID: <20260603165518.96EE11F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260602164635.62517-2-mail@tk154.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Hardware address confusion in mvpp2_buff_hdr_pool_put leading to wild pointer dereference.
--
commit 5455df1ccac8168f900ec83f5414e617fb3ad72f
Author: Til Kaiser <mail@tk154.de>
net: mvpp2: sync RX data at the hardware packet offset
This commit modifies the DMA sync offset for received packets in mvpp2_rx.
It uses dma_sync_single_range_for_cpu with MVPP2_SKB_HEADROOM so the CPU
sync correctly aligns with the data written by the hardware.
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index f442b874bb593..92a701f4fe3f5 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -3946,9 +3946,10 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
> dma_dir = DMA_FROM_DEVICE;
> }
>
> - dma_sync_single_for_cpu(dev->dev.parent, dma_addr,
> - rx_bytes + MVPP2_MH_SIZE,
> - dma_dir);
> + dma_sync_single_range_for_cpu(dev->dev.parent, dma_addr,
> + MVPP2_SKB_HEADROOM,
> + rx_bytes + MVPP2_MH_SIZE,
> + dma_dir);
>
> /* Buffer header not supported */
> if (rx_status & MVPP2_RXD_BUF_HDR)
[Severity: High]
This isn't a bug introduced by this patch, but when rx_status has
MVPP2_RXD_BUF_HDR set, this code jumps to err_drop_frame and eventually
calls mvpp2_buff_hdr_pool_put(). Does mvpp2_buff_hdr_pool_put() swap the
physical and DMA addresses?
Looking at mvpp2_buff_hdr_pool_put():
phys_addr = mvpp2_rxdesc_dma_addr_get(port, rx_desc);
dma_addr = mvpp2_rxdesc_cookie_get(port, rx_desc);
do {
buff_hdr = (struct mvpp2_buff_hdr *)phys_to_virt(phys_addr);
It appears that phys_addr is populated with a DMA address and dma_addr is
populated with the physical cookie.
On systems with an IOMMU where DMA addresses do not map 1:1 to physical
addresses, will calling phys_to_virt() on a DMA address cause a wild pointer
dereference? Could this also corrupt the hardware Buffer Manager pool when
passing these swapped addresses into mvpp2_bm_pool_put()?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260602164635.62517-1-mail@tk154.de?part=1
next prev parent reply other threads:[~2026-06-03 16:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 16:46 [PATCH net v2 0/4] net: mvpp2: fix XDP RX buffer handling Til Kaiser
2026-06-02 16:46 ` [PATCH net v2 1/4] net: mvpp2: sync RX data at the hardware packet offset Til Kaiser
2026-06-03 16:55 ` sashiko-bot [this message]
2026-06-02 16:46 ` [PATCH net v2 2/4] net: mvpp2: limit XDP frame size to the RX buffer Til Kaiser
2026-06-03 16:55 ` sashiko-bot
2026-06-02 16:46 ` [PATCH net v2 3/4] net: mvpp2: do not return retired RX buffers to BM Til Kaiser
2026-06-03 16:55 ` sashiko-bot
2026-06-04 15:45 ` Jakub Kicinski
2026-06-02 16:46 ` [PATCH net v2 4/4] net: mvpp2: build skb from XDP-adjusted data on XDP_PASS Til Kaiser
2026-06-03 16:55 ` sashiko-bot
2026-06-03 13:55 ` [PATCH net v2 0/4] net: mvpp2: fix XDP RX buffer handling Alexander Lobakin
2026-06-04 11:30 ` Marcin Wojtas
2026-06-05 12:13 ` [PATCH net v3 " Til Kaiser
2026-06-05 12:13 ` [PATCH net v3 1/4] net: mvpp2: sync RX data at the hardware packet offset Til Kaiser
2026-06-05 12:13 ` [PATCH net v3 2/4] net: mvpp2: limit XDP frame size to the RX buffer Til Kaiser
2026-06-05 12:13 ` [PATCH net v3 3/4] net: mvpp2: refill RX buffers before XDP or skb use Til Kaiser
2026-06-05 12:13 ` [PATCH net v3 4/4] net: mvpp2: build skb from XDP-adjusted data on XDP_PASS Til Kaiser
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=20260603165518.96EE11F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=mail@tk154.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.