From: Tony Nguyen <anthony.l.nguyen@intel.com>
To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
edumazet@kernel.org, andrew+netdev@lunn.ch,
netdev@vger.kernel.org
Cc: Tjerk Kusters <tkusters@aweta.nl>,
anthony.l.nguyen@intel.com, florian.bezdeka@siemens.com,
meng.ding@siemens.com, p@1g4.org, jiayuan.chen@linux.dev,
pulehui@huawei.com, richardcochran@gmail.com,
stable@vger.kernel.org,
Piotr Kwapulinski <piotr.kwapulinski@intel.com>,
Aleksandr Loktionov <aleksandr.loktionov@intel.com>,
Kurt Kanzenbach <kurt@linutronix.de>,
Alexander Nowlin <alexander.nowlin@intel.com>
Subject: [PATCH net 3/6] igb: only strip Rx timestamp header on the first buffer of a frame
Date: Thu, 1 Oct 2026 15:24:36 -0700 [thread overview]
Message-ID: <20261001222443.3500206-4-anthony.l.nguyen@intel.com> (raw)
In-Reply-To: <20261001222443.3500206-1-anthony.l.nguyen@intel.com>
From: Tjerk Kusters <tkusters@aweta.nl>
When Rx hardware timestamping is enabled (e.g. ptp4l, which configures
HWTSTAMP_FILTER_ALL), the NIC prepends a 16-byte timestamp header to the
first Rx buffer of every received frame. igb_clean_rx_irq() strips this
header inside its per-buffer loop:
if (igb_test_staterr(rx_desc, E1000_RXDADV_STAT_TSIP)) {
ts_hdr_len = igb_ptp_rx_pktstamp(rx_ring->q_vector,
pktbuf, ×tamp);
pkt_offset += ts_hdr_len;
size -= ts_hdr_len;
}
For a frame that spans more than one Rx buffer (e.g. a jumbo frame), this
block runs once per buffer. The timestamp header only exists at the start
of the first buffer, but igb_ptp_rx_pktstamp() is called for every buffer.
On a continuation buffer the data is packet payload, not a timestamp
header. igb_ptp_rx_pktstamp() already has two guards against acting on a
non-header buffer: it returns 0 if PTP is disabled, and returns 0 if the
reserved dwords (the first 8 bytes) are non-zero. Neither is sufficient
here: PTP is enabled, and a continuation buffer whose payload happens to
begin with 8 zero bytes passes the reserved-dword check. In that case the
payload is mistaken for a valid timestamp header and igb_ptp_rx_pktstamp()
returns IGB_TS_HDR_LEN, so the caller strips 16 bytes of real data from
that buffer. A frame spanning N buffers whose continuation buffers start
with zero bytes therefore loses 16 * (N - 1) bytes from its tail.
This is easily triggered by a GigE Vision camera streaming dark frames
(mostly 0x00 pixel data) over jumbo UDP with PTP active on the receiver:
the all-zero frames arrive truncated while frames with non-zero content
are fine. There is no error indication.
No content-based check can reliably tell a continuation buffer that begins
with zero bytes from a real timestamp header, because both are all zero.
Fix it structurally instead: only attempt the strip on the first buffer of
a frame, which is the only buffer that can contain a timestamp header. In
igb_clean_rx_irq() skb is NULL until the first buffer has been processed,
so guarding the strip with !skb restricts it to the first buffer
regardless of payload content.
Fixes: 5379260852b0 ("igb: Fix XDP with PTP enabled")
Cc: stable@vger.kernel.org
Reviewed-by: Piotr Kwapulinski <piotr.kwapulinski@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Signed-off-by: Tjerk Kusters <tkusters@aweta.nl>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index d4a897a8c82c..5c09dc4a2566 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -9069,8 +9069,11 @@ static int igb_clean_rx_irq(struct igb_q_vector *q_vector, const int budget)
rx_buffer = igb_get_rx_buffer(rx_ring, size, &rx_buf_pgcnt);
pktbuf = page_address(rx_buffer->page) + rx_buffer->page_offset;
- /* pull rx packet timestamp if available and valid */
- if (igb_test_staterr(rx_desc, E1000_RXDADV_STAT_TSIP)) {
+ /* pull rx packet timestamp if available and valid; it is only
+ * present on the first buffer of a frame
+ */
+ if (!skb &&
+ igb_test_staterr(rx_desc, E1000_RXDADV_STAT_TSIP)) {
int ts_hdr_len;
ts_hdr_len = igb_ptp_rx_pktstamp(rx_ring->q_vector,
--
2.47.1
next prev parent reply other threads:[~2026-10-01 22:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 22:24 [PATCH net 0/6][pull request] Intel Wired LAN Driver Updates 2026-10-01 (igc, igb, e1000e) Tony Nguyen
2026-10-01 22:24 ` [PATCH net 1/6] igc: Fix RX HW timestamp reporting when NET_RX_BUSY_POLL is disabled Tony Nguyen
2026-10-05 23:02 ` netdev-bot+sashiko
2026-10-08 1:57 ` Jakub Kicinski
2026-10-01 22:24 ` [PATCH net 2/6] igc: only strip RX timestamp header from first buffer Tony Nguyen
2026-10-05 23:02 ` netdev-bot+sashiko
2026-10-07 16:02 ` Paul Moses
2026-10-01 22:24 ` Tony Nguyen [this message]
2026-10-05 23:02 ` [PATCH net 3/6] igb: only strip Rx timestamp header on the first buffer of a frame netdev-bot+sashiko
2026-10-01 22:24 ` [PATCH net 4/6] e1000e: fix IRQ leak when request_irq() fails in e1000_request_msix() Tony Nguyen
2026-10-01 22:24 ` [PATCH net 5/6] e1000e: Fix out-of-bounds MMIO access by validating BAR0 size Tony Nguyen
2026-10-05 23:02 ` netdev-bot+sashiko
2026-10-01 22:24 ` [PATCH net 6/6] e1000e: add system to disable K1 list Tony Nguyen
2026-10-01 22:29 ` [PATCH net 0/6][pull request] Intel Wired LAN Driver Updates 2026-10-01 (igc, igb, e1000e) netdev-bot+sinfo
2026-10-08 2:02 ` Jakub Kicinski
2026-10-08 17:04 ` Tony Nguyen
2026-10-08 2:10 ` patchwork-bot+netdevbpf
2026-10-08 2:10 ` patchwork-bot+netdevbpf
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=20261001222443.3500206-4-anthony.l.nguyen@intel.com \
--to=anthony.l.nguyen@intel.com \
--cc=aleksandr.loktionov@intel.com \
--cc=alexander.nowlin@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=florian.bezdeka@siemens.com \
--cc=jiayuan.chen@linux.dev \
--cc=kuba@kernel.org \
--cc=kurt@linutronix.de \
--cc=meng.ding@siemens.com \
--cc=netdev@vger.kernel.org \
--cc=p@1g4.org \
--cc=pabeni@redhat.com \
--cc=piotr.kwapulinski@intel.com \
--cc=pulehui@huawei.com \
--cc=richardcochran@gmail.com \
--cc=stable@vger.kernel.org \
--cc=tkusters@aweta.nl \
/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