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 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.