All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH net v2] igc: only strip RX timestamp header from first buffer
@ 2026-10-13  1:09 Paul Moses
  2026-10-13  1:15 ` netdev-bot+sinfo
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Paul Moses @ 2026-10-13  1:09 UTC (permalink / raw)
  To: anthony.l.nguyen, przemyslaw.kitszel
  Cc: intel-wired-lan, netdev, andrew+netdev, davem, edumazet, kuba,
	pabeni, aleksandr.loktionov, maciej.fijalkowski, avigailx.dahan,
	stable, linux-kernel

igc_clean_rx_irq() subtracts 16 bytes for TSIP without checking whether
the descriptor contains that much data. On continuation buffers shorter
than 16 bytes, the unsigned length underflows and is stored in the skb
fragment.

From the wire, a 2040-byte timestamped frame with an 8-byte final buffer
produces a fragment length of 0xfffffff8. Bridge forwarding allows that
skb to reach igc TX without passing through IPv4 length validation.

igc_xmit_frame_ring() uses the corrupted length to calculate the
descriptor requirement, overflowing its 16-bit counter. igc_tx_map()
then passes the same length to skb_frag_dma_map(), requesting a nearly
4 GiB DMA mapping.

In both reproductions, the DMA mapping succeeded and the descriptor
loop completed. The corrupted fragment generated 131,072 descriptor
writes. With the tested 256-entry TX ring, this traversed the ring
512 times, repeatedly overwriting descriptors.

The TX queue then stalled. NETDEV WATCHDOG reported "transmit queue 0
timed out" after about 5.5 seconds, followed by an adapter reset.
The first occurrence also triggered a warning in the NAPI poll path.

Only subtract the inline timestamp header from the first buffer of
an skb-assembled packet. Continuation buffers are appended as fragments
and do not contain an inline timestamp.

Fixes: e1ed4f92a625 ("igc: Refactor Rx timestamp handling")
Cc: stable@vger.kernel.org
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Tested-by: Avigail Dahan <avigailx.dahan@intel.com>
Signed-off-by: Paul Moses <p@1g4.org>
---
v1...v2
    - improve commit message
    - no code changes
---
Logs:

[  540.236838] WARNING: at igc_poll+0x4f42/0x7660 [igc], CPU#3: swapper/3/0
[  540.372991] Modules linked in: igc
[  540.413904] CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 7.3.0-rc6+ #4 PREEMPT 
[  540.505951] RIP: 0010:igc_poll+0x4f42/0x7660 [igc]
[  540.563556] Code: 00 e8 b2 c6 eb f0 85 c0 74 27 48 c7 44 24 30 00 00 00 00 45 89 e7 8b ac 24 e0 00 00 00 4c 8b b4 24 d8 00 00 00 e9 b2 e6 ff ff <0f> 0b e9 10 ec ff ff 49 83 c6 74 4c 89 f0 48 c1 e8 03 42 0f b6 04
[  540.789183] RSP: 0018:ffffc900003e0b68 EFLAGS: 00010282
[  540.852006] RAX: ffffc90000469100 RBX: ffff88824b711380 RCX: 0000000000000800
[  540.937776] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff888205d33468
[  541.023541] RBP: 1ffff110496e226f R08: ffff888205d3346f R09: 1ffff11040ba668d
[  541.109317] R10: dffffc0000000000 R11: ffffed1040ba668e R12: 0000000000000000
[  541.195086] R13: 1ffff110496e2270 R14: ffffc900004690f0 R15: ffffea0004485d40
[  541.280849] FS:  0000000000000000(0000) GS:ffff8887ac2a5000(0000) knlGS:0000000000000000
[  541.378102] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  541.447186] CR2: 000079fdfe44f188 CR3: 0000000109c68003 CR4: 0000000000f70ef0
[  541.532974] PKRU: 55555554
[  541.565530] Call Trace:
[  541.594960]  <IRQ>
[  541.619184]  __napi_poll+0x91/0x380
[  541.661120]  net_rx_action+0x4e0/0xbc0
[  541.706209]  handle_softirqs+0x173/0x4d0
[  541.753373]  ? handle_edge_irq+0x1af/0x710
[  541.802631]  __irq_exit_rcu+0x63/0xd0
[  541.846664]  common_interrupt+0x81/0x90
[  541.892793]  </IRQ>
[  541.918044]  <TASK>
[  541.943297]  asm_common_interrupt+0x26/0x40
[  541.993593] RIP: 0010:mwait_idle+0x49/0x60
[  542.042838] Code: 80 0e 40 48 f7 06 10 00 00 00 75 1f 48 89 f0 0f 1f 00 31 c9 31 d2 0f 01 c8 48 f7 06 10 00 00 00 75 09 31 c0 31 c9 fb 0f 01 c9 <fa> f0 80 26 bf c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
[  542.268428] RSP: 0018:ffffc9000025fed8 EFLAGS: 00000246
[  542.331248] RAX: 0000000000000000 RBX: ffff88810091c400 RCX: 0000000000000000
[  542.417000] RDX: 0000000000000000 RSI: ffff88810091c400 RDI: 000000000022e00c
[  542.502770] RBP: 1ffff11020123880 R08: ffff8887608f06d3 R09: 1ffff110ec11e0da
[  542.588551] R10: dffffc0000000000 R11: ffffed10ec11e0db R12: 0000000000000000
[  542.674330] R13: 0000000000000000 R14: dffffc0000000000 R15: 0000000000000000
[  542.760111]  default_idle_call+0x39/0x60
[  542.807277]  do_idle+0xff/0x340
[  542.845051]  cpu_startup_entry+0x48/0x70
[  542.892212]  start_secondary+0xfc/0x100
[  542.938337]  common_startup_64+0x12c/0x147
[  542.987604]  </TASK>
[  543.013881] ---[ end trace 0000000000000000 ]---
[  543.069828] igc 0000:02:00.0: Using 39-bit DMA addresses
[  548.627473] igc 0000:02:00.0 enp2s0: NETDEV WATCHDOG: CPU: 2: transmit queue 0 timed out 5480 ms
[  548.627546] igc 0000:02:00.0 enp2s0: Register Dump
[  548.627556] igc 0000:02:00.0 enp2s0: Register Name   Value
[  548.627566] igc 0000:02:00.0 enp2s0: CTRL            581c0040
[  548.627581] igc 0000:02:00.0 enp2s0: STATUS          40680683
[  548.627590] igc 0000:02:00.0 enp2s0: CTRL_EXT        100000c0
[  548.627599] igc 0000:02:00.0 enp2s0: MDIC            1805dde1
[  548.627607] igc 0000:02:00.0 enp2s0: ICR             00000081
[  548.627616] igc 0000:02:00.0 enp2s0: RCTL            04408022
[  548.627630] igc 0000:02:00.0 enp2s0: RDLEN[0-3]      00001000 00001000 00001000 00001000
[  548.627649] igc 0000:02:00.0 enp2s0: RDH[0-3]        00000013 0000000c 00000000 00000000
[  548.627668] igc 0000:02:00.0 enp2s0: RDT[0-3]        00000012 0000000b 000000ff 000000ff
[  548.627687] igc 0000:02:00.0 enp2s0: RXDCTL[0-3]     02040808 02040808 02040808 02040808
[  548.627706] igc 0000:02:00.0 enp2s0: RDBAL[0-3]      ffffb000 ffffa000 ffff9000 ffff8000
[  548.627725] igc 0000:02:00.0 enp2s0: RDBAH[0-3]      00000000 00000000 00000000 00000000
[  548.627734] igc 0000:02:00.0 enp2s0: TCTL            a503f0fa
[  548.627748] igc 0000:02:00.0 enp2s0: TDBAL[0-3]      fffff000 ffffe000 ffffd000 ffffc000
[  548.627766] igc 0000:02:00.0 enp2s0: TDBAH[0-3]      00000000 00000000 00000000 00000000
[  548.627780] igc 0000:02:00.0 enp2s0: TDLEN[0-3]      00001000 00001000 00001000 00001000
[  548.627799] igc 0000:02:00.0 enp2s0: TDH[0-3]        00000013 0000000c 00000000 00000018
[  548.627814] igc 0000:02:00.0 enp2s0: TDT[0-3]        00000013 0000000c 00000000 00000018
[  548.627828] igc 0000:02:00.0 enp2s0: TXDCTL[0-3]     02100108 02100108 02100108 02100108
[  548.627837] igc 0000:02:00.0 enp2s0: Reset adapter
[  552.415852] igc 0000:02:00.0 enp2s0: NIC Link is Up 2500 Mbps Full Duplex, Flow Control: RX/TX
[  607.597798] igc 0000:02:00.0 enp2s0: NETDEV WATCHDOG: CPU: 0: transmit queue 0 timed out 5680 ms
[  607.597890] igc 0000:02:00.0 enp2s0: Register Dump
[  607.597901] igc 0000:02:00.0 enp2s0: Register Name   Value
[  607.597911] igc 0000:02:00.0 enp2s0: CTRL            581c0040
[  607.597926] igc 0000:02:00.0 enp2s0: STATUS          40680683
[  607.597935] igc 0000:02:00.0 enp2s0: CTRL_EXT        100000c0
[  607.597944] igc 0000:02:00.0 enp2s0: MDIC            1805dde1
[  607.597952] igc 0000:02:00.0 enp2s0: ICR             00000081
[  607.597962] igc 0000:02:00.0 enp2s0: RCTL            04408022
[  607.597976] igc 0000:02:00.0 enp2s0: RDLEN[0-3]      00001000 00001000 00001000 00001000
[  607.597996] igc 0000:02:00.0 enp2s0: RDH[0-3]        0000000a 00000006 00000000 00000000
[  607.598015] igc 0000:02:00.0 enp2s0: RDT[0-3]        00000009 00000005 000000ff 000000ff
[  607.598034] igc 0000:02:00.0 enp2s0: RXDCTL[0-3]     02040808 02040808 02040808 02040808
[  607.598053] igc 0000:02:00.0 enp2s0: RDBAL[0-3]      ffffb000 ffffa000 ffff9000 ffff8000
[  607.598072] igc 0000:02:00.0 enp2s0: RDBAH[0-3]      00000000 00000000 00000000 00000000
[  607.598081] igc 0000:02:00.0 enp2s0: TCTL            a503f0fa
[  607.598094] igc 0000:02:00.0 enp2s0: TDBAL[0-3]      fffff000 ffffe000 ffffd000 ffffc000
[  607.598109] igc 0000:02:00.0 enp2s0: TDBAH[0-3]      00000000 00000000 00000000 00000000
[  607.598124] igc 0000:02:00.0 enp2s0: TDLEN[0-3]      00001000 00001000 00001000 00001000
[  607.598139] igc 0000:02:00.0 enp2s0: TDH[0-3]        00000008 00000006 00000000 0000000c
[  607.598153] igc 0000:02:00.0 enp2s0: TDT[0-3]        00000008 00000006 00000000 0000000c
[  607.598168] igc 0000:02:00.0 enp2s0: TXDCTL[0-3]     02100108 02100108 02100108 02100108
[  607.598176] igc 0000:02:00.0 enp2s0: Reset adapter
[  611.790143] igc 0000:02:00.0 enp2s0: NIC Link is Up 2500 Mbps Full Duplex, Flow Control: RX/TX

---

 drivers/net/ethernet/intel/igc/igc_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
index 1fb5f3cbe93c..41b293dc10c3 100644
--- a/drivers/net/ethernet/intel/igc/igc_main.c
+++ b/drivers/net/ethernet/intel/igc/igc_main.c
@@ -2639,7 +2639,8 @@ static int igc_clean_rx_irq(struct igc_q_vector *q_vector, const int budget)
 
 		pktbuf = page_address(rx_buffer->page) + rx_buffer->page_offset;
 
-		if (igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP)) {
+		if (!skb &&
+		    igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP)) {
 			ctx.rx_ts = pktbuf;
 			pkt_offset = IGC_TS_HDR_LEN;
 			size -= IGC_TS_HDR_LEN;
-- 
2.56.GIT



^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH net v2] igc: only strip RX timestamp header from first buffer
  2026-10-13  1:09 [PATCH net v2] igc: only strip RX timestamp header from first buffer Paul Moses
@ 2026-10-13  1:15 ` netdev-bot+sinfo
  2026-10-14  1:10 ` sashiko-bot
  2026-10-14  1:59 ` netdev-bot+sashiko
  2 siblings, 0 replies; 7+ messages in thread
From: netdev-bot+sinfo @ 2026-10-13  1:15 UTC (permalink / raw)
  To: Paul Moses
  Cc: anthony.l.nguyen, przemyslaw.kitszel, intel-wired-lan, netdev,
	andrew+netdev, davem, edumazet, kuba, pabeni, aleksandr.loktionov,
	maciej.fijalkowski, avigailx.dahan, stable, linux-kernel

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH net v2] igc: only strip RX timestamp header from first buffer
  2026-10-13  1:09 [PATCH net v2] igc: only strip RX timestamp header from first buffer Paul Moses
  2026-10-13  1:15 ` netdev-bot+sinfo
@ 2026-10-14  1:10 ` sashiko-bot
  2026-10-14  1:40   ` Paul Moses
  2026-10-14  1:59 ` netdev-bot+sashiko
  2 siblings, 1 reply; 7+ messages in thread
From: sashiko-bot @ 2026-10-14  1:10 UTC (permalink / raw)
  To: Paul Moses; +Cc: intel-wired-lan

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] igc: Frame Preemption express packets (mPackets) lose TSIP stripping when interleaved
- [High] igc: incomplete TSIP underflow fix due to XDP fragment drop
--

commit 61d038c91b93b927335a69df60dbf6cc817c79e2
Author: Paul Moses <p@1g4.org>
igc: only strip RX timestamp header from first buffer

This patch modifies the RX path to only subtract the 16-byte TSIP inline
timestamp from the first buffer of an skb-assembled packet. This is intended
to prevent an unsigned length underflow on continuation buffers shorter than
16 bytes.

> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
> index 1fb5f3cbe93c5..41b293dc10c3a 100644
> --- a/drivers/net/ethernet/intel/igc/igc_main.c
> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
> @@ -2639,7 +2639,8 @@ static int igc_clean_rx_irq(struct igc_q_vector *q_vector, const int budget)
>  
>  		pktbuf = page_address(rx_buffer->page) + rx_buffer->page_offset;
>  
> -		if (igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP)) {
> +		if (!skb &&
> +		    igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP)) {
>  			ctx.rx_ts = pktbuf;
>  			pkt_offset = IGC_TS_HDR_LEN;
>  			size -= IGC_TS_HDR_LEN;
>  		}

[Severity: High]
Does this condition corrupt interleaved express packets?

Frame Preemption allows express packets (mPackets) to be interleaved in the 
RX ring while a preemptable packet is being assembled. When an mPacket 
arrives during this assembly, skb will be non-NULL.

Because of the new !skb check, the mPacket's TSIP header won't be stripped,
leaving pkt_offset at 0 and size unmodified.

Shortly after this check in igc_clean_rx_irq(), the mPacket is handled:

    if (igc_fpe_is_pmac_enabled(adapter) &&
        igc_fpe_handle_mpacket(adapter, rx_desc, size, pktbuf + pkt_offset)) {
            /* Advance the ring next-to-clean */
            igc_is_non_eop(rx_ring, rx_desc);
            ...

Will this pass the unadjusted size and unstripped TSIP header (pktbuf + 0)
into igc_fpe_handle_mpacket(), treating the 16-byte hardware timestamp as
packet payload?

[Severity: High]
Does this fix fully prevent the continuation fragment underflow?

The patch attempts to fix a queue stall caused by an integer underflow on
continuation fragments, but relies on skb being non-NULL to detect them.

If XDP is enabled and the administrator has enabled the rx-all feature
(disabling MTU enforcement), an oversized packet can be split across multiple
descriptors. If the XDP program drops the first descriptor (e.g., returning
XDP_DROP), skb remains NULL.

When the loop hits igc_is_non_eop() and continues to the next descriptor,
skb will still be NULL. If that continuation fragment is shorter than
16 bytes and has the TSIP status bit set, won't this check evaluate to true
and cause size to underflow exactly as it did before the patch?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013010854.4068874-1-p@1g4.org?part=1

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH net v2] igc: only strip RX timestamp header from first buffer
  2026-10-14  1:10 ` sashiko-bot
@ 2026-10-14  1:40   ` Paul Moses
  2026-10-14  1:55     ` Paul Moses
  0 siblings, 1 reply; 7+ messages in thread
From: Paul Moses @ 2026-10-14  1:40 UTC (permalink / raw)
  To: intel-wired-lan@lists.osuosl.org





On Tuesday, October 13th, 2026 at 8:10 PM, sashiko-bot@kernel.org <sashiko-bot@kernel.org> wrote:

> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] igc: Frame Preemption express packets (mPackets) lose TSIP stripping when interleaved
> - [High] igc: incomplete TSIP underflow fix due to XDP fragment drop
> --
> 
> commit 61d038c91b93b927335a69df60dbf6cc817c79e2
> Author: Paul Moses <p@1g4.org>
> igc: only strip RX timestamp header from first buffer
> 
> This patch modifies the RX path to only subtract the 16-byte TSIP inline
> timestamp from the first buffer of an skb-assembled packet. This is intended
> to prevent an unsigned length underflow on continuation buffers shorter than
> 16 bytes.
> 
> > diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
> > index 1fb5f3cbe93c5..41b293dc10c3a 100644
> > --- a/drivers/net/ethernet/intel/igc/igc_main.c
> > +++ b/drivers/net/ethernet/intel/igc/igc_main.c
> > @@ -2639,7 +2639,8 @@ static int igc_clean_rx_irq(struct igc_q_vector *q_vector, const int budget)
> >
> >  		pktbuf = page_address(rx_buffer->page) + rx_buffer->page_offset;
> >
> > -		if (igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP)) {
> > +		if (!skb &&
> > +		    igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP)) {
> >  			ctx.rx_ts = pktbuf;
> >  			pkt_offset = IGC_TS_HDR_LEN;
> >  			size -= IGC_TS_HDR_LEN;
> >  		}
> 
> [Severity: High]
> Does this condition corrupt interleaved express packets?
> 
> Frame Preemption allows express packets (mPackets) to be interleaved in the
> RX ring while a preemptable packet is being assembled. When an mPacket
> arrives during this assembly, skb will be non-NULL.
> 
> Because of the new !skb check, the mPacket's TSIP header won't be stripped,
> leaving pkt_offset at 0 and size unmodified.
> 
> Shortly after this check in igc_clean_rx_irq(), the mPacket is handled:
> 
>     if (igc_fpe_is_pmac_enabled(adapter) &&
>         igc_fpe_handle_mpacket(adapter, rx_desc, size, pktbuf + pkt_offset)) {
>             /* Advance the ring next-to-clean */
>             igc_is_non_eop(rx_ring, rx_desc);
>             ...
> 
> Will this pass the unadjusted size and unstripped TSIP header (pktbuf + 0)
> into igc_fpe_handle_mpacket(), treating the 16-byte hardware timestamp as
> packet payload?

It'll drop, not do that, but I'll fix in this series.


> 
> [Severity: High]
> Does this fix fully prevent the continuation fragment underflow?
> 
> The patch attempts to fix a queue stall caused by an integer underflow on
> continuation fragments, but relies on skb being non-NULL to detect them.
> 
> If XDP is enabled and the administrator has enabled the rx-all feature
> (disabling MTU enforcement), an oversized packet can be split across multiple
> descriptors. If the XDP program drops the first descriptor (e.g., returning
> XDP_DROP), skb remains NULL.
> 
> When the loop hits igc_is_non_eop() and continues to the next descriptor,
> skb will still be NULL. If that continuation fragment is shorter than
> 16 bytes and has the TSIP status bit set, won't this check evaluate to true
> and cause size to underflow exactly as it did before the patch?
> 

No, xdp was still no bueno, but I've had some breakthroughs already today and
this is all mostly finished, I'll submit v3 series shortly.

Thanks,
Paul



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH net v2] igc: only strip RX timestamp header from first buffer
  2026-10-14  1:40   ` Paul Moses
@ 2026-10-14  1:55     ` Paul Moses
  0 siblings, 0 replies; 7+ messages in thread
From: Paul Moses @ 2026-10-14  1:55 UTC (permalink / raw)
  To: intel-wired-lan@lists.osuosl.org





On Tuesday, October 13th, 2026 at 8:40 PM, Paul Moses <p@1g4.org> wrote:

> 
> 
> 
> 
> On Tuesday, October 13th, 2026 at 8:10 PM, sashiko-bot@kernel.org <sashiko-bot@kernel.org> wrote:
> 
> > Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> > - [High] igc: Frame Preemption express packets (mPackets) lose TSIP stripping when interleaved
> > - [High] igc: incomplete TSIP underflow fix due to XDP fragment drop
> > --
> >
> > commit 61d038c91b93b927335a69df60dbf6cc817c79e2
> > Author: Paul Moses <p@1g4.org>
> > igc: only strip RX timestamp header from first buffer
> >
> > This patch modifies the RX path to only subtract the 16-byte TSIP inline
> > timestamp from the first buffer of an skb-assembled packet. This is intended
> > to prevent an unsigned length underflow on continuation buffers shorter than
> > 16 bytes.
> >
> > > diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
> > > index 1fb5f3cbe93c5..41b293dc10c3a 100644
> > > --- a/drivers/net/ethernet/intel/igc/igc_main.c
> > > +++ b/drivers/net/ethernet/intel/igc/igc_main.c
> > > @@ -2639,7 +2639,8 @@ static int igc_clean_rx_irq(struct igc_q_vector *q_vector, const int budget)
> > >
> > >  		pktbuf = page_address(rx_buffer->page) + rx_buffer->page_offset;
> > >
> > > -		if (igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP)) {
> > > +		if (!skb &&
> > > +		    igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP)) {
> > >  			ctx.rx_ts = pktbuf;
> > >  			pkt_offset = IGC_TS_HDR_LEN;
> > >  			size -= IGC_TS_HDR_LEN;
> > >  		}
> >
> > [Severity: High]
> > Does this condition corrupt interleaved express packets?
> >
> > Frame Preemption allows express packets (mPackets) to be interleaved in the
> > RX ring while a preemptable packet is being assembled. When an mPacket
> > arrives during this assembly, skb will be non-NULL.
> >
> > Because of the new !skb check, the mPacket's TSIP header won't be stripped,
> > leaving pkt_offset at 0 and size unmodified.
> >
> > Shortly after this check in igc_clean_rx_irq(), the mPacket is handled:
> >
> >     if (igc_fpe_is_pmac_enabled(adapter) &&
> >         igc_fpe_handle_mpacket(adapter, rx_desc, size, pktbuf + pkt_offset)) {
> >             /* Advance the ring next-to-clean */
> >             igc_is_non_eop(rx_ring, rx_desc);
> >             ...
> >
> > Will this pass the unadjusted size and unstripped TSIP header (pktbuf + 0)
> > into igc_fpe_handle_mpacket(), treating the 16-byte hardware timestamp as
> > packet payload?
> 
> It'll drop, not do that, but I'll fix in this series.
> 
> 
> >
> > [Severity: High]
> > Does this fix fully prevent the continuation fragment underflow?
> >
> > The patch attempts to fix a queue stall caused by an integer underflow on
> > continuation fragments, but relies on skb being non-NULL to detect them.
> >
> > If XDP is enabled and the administrator has enabled the rx-all feature
> > (disabling MTU enforcement), an oversized packet can be split across multiple
> > descriptors. If the XDP program drops the first descriptor (e.g., returning
> > XDP_DROP), skb remains NULL.
> >
> > When the loop hits igc_is_non_eop() and continues to the next descriptor,
> > skb will still be NULL. If that continuation fragment is shorter than
> > 16 bytes and has the TSIP status bit set, won't this check evaluate to true
> > and cause size to underflow exactly as it did before the patch?
> >
> 
> No, xdp was still no bueno, but I've had some breakthroughs already today and
> this is all mostly finished, I'll submit v3 series shortly.
> 
> Thanks,
> Paul
> 
> 

Is this list private? Can I openly discuss remaining security matters?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH net v2] igc: only strip RX timestamp header from first buffer
  2026-10-13  1:09 [PATCH net v2] igc: only strip RX timestamp header from first buffer Paul Moses
  2026-10-13  1:15 ` netdev-bot+sinfo
  2026-10-14  1:10 ` sashiko-bot
@ 2026-10-14  1:59 ` netdev-bot+sashiko
  2026-10-14  5:43   ` Paul Moses
  2 siblings, 1 reply; 7+ messages in thread
From: netdev-bot+sashiko @ 2026-10-14  1:59 UTC (permalink / raw)
  To: p
  Cc: anthony.l.nguyen, przemyslaw.kitszel, intel-wired-lan, netdev,
	andrew+netdev, davem, edumazet, kuba, pabeni, aleksandr.loktionov,
	maciej.fijalkowski, avigailx.dahan, stable, linux-kernel

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider.

Critical: 0 · High: 2 · Medium: 0 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [High] The patch fixes the TSIP length underflow only in
  igc_clean_rx_irq().
- [High] In igc_clean_rx_irq(), the new condition `if (!skb &&
  igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP))` uses `!skb` to mean…

--

igc: only strip RX timestamp header from first buffer

This patch changes igc_clean_rx_irq() so the 16-byte inline RX timestamp
header is only stripped when no skb is in progress. Before, a continuation
buffer shorter than 16 bytes could underflow the unsigned length and
produce a skb fragment of almost 4 GiB.

> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
> index 1fb5f3cbe93c5..41b293dc10c3a 100644
> --- a/drivers/net/ethernet/intel/igc/igc_main.c
> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
> @@ -2639,7 +2639,8 @@ static int igc_clean_rx_irq(struct igc_q_vector *q_vector, const int budget)
>  
>  		pktbuf = page_address(rx_buffer->page) + rx_buffer->page_offset;
>  
> -		if (igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP)) {
> +		if (!skb &&
> +		    igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP)) {

[Severity: High]
Is !skb a reliable first-buffer test when an XDP program is attached?

Suppose the XDP program returns a non-PASS verdict (CONSUMED, TX or
REDIRECT) for the first, non-EOP buffer of a multi-descriptor frame. No skb
gets built, and the loop moves on with skb still NULL:

		/* fetch next buffer in frame if non-eop */
		if (igc_is_non_eop(rx_ring, rx_desc))
			continue;

On the next continuation descriptor, !skb is still true, so the TSIP branch
subtracts IGC_TS_HDR_LEN again. If that continuation holds fewer than 16
bytes, size wraps.

The wrapped size then goes to xdp_prepare_buff(), and the continuation is
run through XDP as a new frame with data_end before data. On XDP_PASS, both
igc_build_skb() and igc_construct_skb() compute:

	unsigned int size = xdp->data_end - xdp->data;

That comes out to about 4 GiB:

- igc_build_skb() passes it to __skb_put(). On PAGE_SIZE >= 8192,
  igc_get_rx_frame_truesize() also wraps to a tiny truesize, so
  napi_build_skb() would place skb_shared_info inside the packet data.
- igc_construct_skb() turns it into a fragment of almost 4 GiB. That looks
  like the same corrupted skb the commit message describes.

Can this be reached from the wire? On PAGE_SIZE >= 8192, igc_set_rx_mode()
never clamps RLPML:

#if (PAGE_SIZE < 8192)
	if (adapter->max_frame_size <= IGC_MAX_FRAME_BUILD_SKB)
		rlpml = IGC_MAX_FRAME_BUILD_SKB;
#endif
	wr32(IGC_RLPML, rlpml);

So the hardware still accepts jumbo frames even though XDP limits the MTU to
1500, and with XDP the ring uses 3072-byte buffers. A remote frame that
leaves 1 to 15 bytes in the second descriptor would hit this.

Would it be safer to track start-of-frame explicitly, or to drop the rest of
the frame's descriptors after a non-PASS verdict? Another option is to
reject size < IGC_TS_HDR_LEN before the subtraction.

>  			ctx.rx_ts = pktbuf;
>  			pkt_offset = IGC_TS_HDR_LEN;
>  			size -= IGC_TS_HDR_LEN;

[Severity: High]
The same unchecked subtraction is still present in the AF_XDP zero-copy
path. igc_clean_rx_irq_zc() strips the header from every descriptor with
TSIP set. There is no first-buffer gate and no size check:

		if (igc_test_staterr(desc, IGC_RXDADV_STAT_TSIP)) {
			ctx->rx_ts = bi->xdp->data;

			bi->xdp->data += IGC_TS_HDR_LEN;
			...
			size -= IGC_TS_HDR_LEN;
		} else {
			ctx->rx_ts = NULL;
		}

		bi->xdp->data_end = bi->xdp->data + size;

Can zero-copy frames span descriptors at MTU 1500?
igc_configure_rx_ring() programs the XSK frame size through
IGC_SRRCTL_BSIZEPKT(), which is (x) / 1024. With 2048-byte chunks the frame
size is 1792, so the hardware buffer becomes 1 KB.

igc_xdp_enable_pool() only checks:

	if (frame_size < ETH_FRAME_LEN + VLAN_HLEN * 2) {

That accepts 1792 without allowing for the 1 KB rounding or the 16-byte
inline timestamp, even though the comment there says frames should not
span multiple buffers.

On 4K pages RLPML is IGC_MAX_FRAME_BUILD_SKB. A received frame of about
1009 to 1023 bytes, plus the timestamp header, would leave 1 to 15 bytes in
a second descriptor.

The reproduction in the commit message suggests TSIP is set on such
continuation descriptors. If so, size wraps here and data_end ends up about
4 GiB past the XSK chunk.

Wouldn't that let the XDP program's packet bounds checks pass for offsets
past the chunk? On XDP_REDIRECT, it would also report a bogus length to the
XSK socket.

Should igc_clean_rx_irq_zc() get a similar fix? Should
igc_xdp_enable_pool() also account for the 1 KB SRRCTL granularity and the
inline timestamp?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261013010854.4068874-1-p%401g4.org

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH net v2] igc: only strip RX timestamp header from first buffer
  2026-10-14  1:59 ` netdev-bot+sashiko
@ 2026-10-14  5:43   ` Paul Moses
  0 siblings, 0 replies; 7+ messages in thread
From: Paul Moses @ 2026-10-14  5:43 UTC (permalink / raw)
  To: netdev-bot+sashiko
  Cc: anthony.l.nguyen, przemyslaw.kitszel, intel-wired-lan, netdev,
	andrew+netdev, davem, edumazet, kuba, pabeni, aleksandr.loktionov,
	maciej.fijalkowski, avigailx.dahan, stable, linux-kernel

On Tuesday, October 13th, 2026 at 8:59 PM, netdev-bot+sashiko@kernel.org <netdev-bot+sashiko@kernel.org> wrote:

> Thank you for your contribution! Sashiko AI review found 2 potential
> issue(s) to consider.
> 
> Critical: 0 · High: 2 · Medium: 0 · Low: 0
> 
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
> 
> - [High] The patch fixes the TSIP length underflow only in
>   igc_clean_rx_irq().
> - [High] In igc_clean_rx_irq(), the new condition `if (!skb &&
>   igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP))` uses `!skb` to mean…
> 
> --
> 
> igc: only strip RX timestamp header from first buffer
> 
> This patch changes igc_clean_rx_irq() so the 16-byte inline RX timestamp
> header is only stripped when no skb is in progress. Before, a continuation
> buffer shorter than 16 bytes could underflow the unsigned length and
> produce a skb fragment of almost 4 GiB.
> 
> > diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
> > index 1fb5f3cbe93c5..41b293dc10c3a 100644
> > --- a/drivers/net/ethernet/intel/igc/igc_main.c
> > +++ b/drivers/net/ethernet/intel/igc/igc_main.c
> > @@ -2639,7 +2639,8 @@ static int igc_clean_rx_irq(struct igc_q_vector *q_vector, const int budget)
> >
> >  		pktbuf = page_address(rx_buffer->page) + rx_buffer->page_offset;
> >
> > -		if (igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP)) {
> > +		if (!skb &&
> > +		    igc_test_staterr(rx_desc, IGC_RXDADV_STAT_TSIP)) {
> 
> [Severity: High]
> Is !skb a reliable first-buffer test when an XDP program is attached?
> 
> Suppose the XDP program returns a non-PASS verdict (CONSUMED, TX or
> REDIRECT) for the first, non-EOP buffer of a multi-descriptor frame. No skb
> gets built, and the loop moves on with skb still NULL:
> 
> 		/* fetch next buffer in frame if non-eop */
> 		if (igc_is_non_eop(rx_ring, rx_desc))
> 			continue;
> 
> On the next continuation descriptor, !skb is still true, so the TSIP branch
> subtracts IGC_TS_HDR_LEN again. If that continuation holds fewer than 16
> bytes, size wraps.
> 
> The wrapped size then goes to xdp_prepare_buff(), and the continuation is
> run through XDP as a new frame with data_end before data. On XDP_PASS, both
> igc_build_skb() and igc_construct_skb() compute:
> 
> 	unsigned int size = xdp->data_end - xdp->data;
> 
> That comes out to about 4 GiB:
> 
> - igc_build_skb() passes it to __skb_put(). On PAGE_SIZE >= 8192,
>   igc_get_rx_frame_truesize() also wraps to a tiny truesize, so
>   napi_build_skb() would place skb_shared_info inside the packet data.
> - igc_construct_skb() turns it into a fragment of almost 4 GiB. That looks
>   like the same corrupted skb the commit message describes.
> 
> Can this be reached from the wire? On PAGE_SIZE >= 8192, igc_set_rx_mode()
> never clamps RLPML:
> 
> #if (PAGE_SIZE < 8192)
> 	if (adapter->max_frame_size <= IGC_MAX_FRAME_BUILD_SKB)
> 		rlpml = IGC_MAX_FRAME_BUILD_SKB;
> #endif
> 	wr32(IGC_RLPML, rlpml);
> 
> So the hardware still accepts jumbo frames even though XDP limits the MTU to
> 1500, and with XDP the ring uses 3072-byte buffers. A remote frame that
> leaves 1 to 15 bytes in the second descriptor would hit this.
> 
> Would it be safer to track start-of-frame explicitly, or to drop the rest of
> the frame's descriptors after a non-PASS verdict? Another option is to
> reject size < IGC_TS_HDR_LEN before the subtraction.
> 
> >  			ctx.rx_ts = pktbuf;
> >  			pkt_offset = IGC_TS_HDR_LEN;
> >  			size -= IGC_TS_HDR_LEN;
> 
> [Severity: High]
> The same unchecked subtraction is still present in the AF_XDP zero-copy
> path. igc_clean_rx_irq_zc() strips the header from every descriptor with
> TSIP set. There is no first-buffer gate and no size check:
> 
> 		if (igc_test_staterr(desc, IGC_RXDADV_STAT_TSIP)) {
> 			ctx->rx_ts = bi->xdp->data;
> 
> 			bi->xdp->data += IGC_TS_HDR_LEN;
> 			...
> 			size -= IGC_TS_HDR_LEN;
> 		} else {
> 			ctx->rx_ts = NULL;
> 		}
> 
> 		bi->xdp->data_end = bi->xdp->data + size;
> 
> Can zero-copy frames span descriptors at MTU 1500?
> igc_configure_rx_ring() programs the XSK frame size through
> IGC_SRRCTL_BSIZEPKT(), which is (x) / 1024. With 2048-byte chunks the frame
> size is 1792, so the hardware buffer becomes 1 KB.
> 
> igc_xdp_enable_pool() only checks:
> 
> 	if (frame_size < ETH_FRAME_LEN + VLAN_HLEN * 2) {
> 
> That accepts 1792 without allowing for the 1 KB rounding or the 16-byte
> inline timestamp, even though the comment there says frames should not
> span multiple buffers.
> 
> On 4K pages RLPML is IGC_MAX_FRAME_BUILD_SKB. A received frame of about
> 1009 to 1023 bytes, plus the timestamp header, would leave 1 to 15 bytes in
> a second descriptor.
> 
> The reproduction in the commit message suggests TSIP is set on such
> continuation descriptors. If so, size wraps here and data_end ends up about
> 4 GiB past the XSK chunk.
> 
> Wouldn't that let the XDP program's packet bounds checks pass for offsets
> past the chunk? On XDP_REDIRECT, it would also report a bogus length to the
> XSK socket.
> 
> Should igc_clean_rx_irq_zc() get a similar fix? Should
> igc_xdp_enable_pool() also account for the 1 KB SRRCTL granularity and the
> inline timestamp?
> 
> --
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261013010854.4068874-1-p%401g4.org
> 

Yes, there's work needed elsewhere, but it's entirely independent of my fix. It's 
questionable how much of this is even reachable and if any impact whatsoever. 

Here's what I can reproduce with and without kasan and what my patch fixes. You are on your 
own on the rest.

I'm sorry, if only there were more time...

Good luck.

[  981.289013] ==================================================================
[  981.289028] BUG: KASAN: slab-use-after-free in sk_skb_reason_drop+0x36/0x280
[  981.289051] Write of size 4 at addr ffff888201376fd4 by task kworker/7:2/92

[  981.289069] CPU: 7 UID: 0 PID: 92 Comm: kworker/7:2 Tainted: G        W           7.3.0-rc6+ #4 PREEMPT 
[  981.289083] Tainted: [W]=WARN
[  981.289088] Workqueue: events igc_reset_task [igc]
[  981.289152] Call Trace:
[  981.289158]  <TASK>
[  981.289163]  dump_stack_lvl+0x43/0x60
[  981.289177]  print_address_description+0x55/0x1d0
[  981.289188]  ? sk_skb_reason_drop+0x36/0x280
[  981.289196]  print_report+0x58/0x70
[  981.289203]  kasan_report+0x117/0x150
[  981.289213]  ? dev_kfree_skb_any_reason+0x4/0x180
[  981.289221]  ? sk_skb_reason_drop+0x36/0x280
[  981.289229]  kasan_check_range+0x3c7/0x3f0
[  981.289238]  sk_skb_reason_drop+0x36/0x280
[  981.289246]  igc_clean_tx_ring+0x24a/0xb40 [igc]
[  981.289296]  igc_down+0x7b1/0xc70 [igc]
[  981.289339]  igc_reinit_locked+0x5a/0x80 [igc]
[  981.289379]  igc_reset_task+0xca/0xd0 [igc]
[  981.289418]  process_scheduled_works+0x805/0xf10
[  981.289435]  worker_thread+0x8d2/0xc60
[  981.289443]  ? __schedule+0x1011/0x2330
[  981.289462]  kthread+0x2c9/0x3a0
[  981.289468]  ? __pfx_worker_thread+0x10/0x10
[  981.289477]  ? __pfx_kthread+0x10/0x10
[  981.289487]  ret_from_fork+0x14d/0x3f0
[  981.289496]  ? __pfx_kthread+0x10/0x10
[  981.289505]  ret_from_fork_asm+0x1a/0x30
[  981.289517]  </TASK>

[  981.289523] Allocated by task 0:
[  981.289529]  kasan_save_track+0x3e/0x80
[  981.289541]  __kasan_mempool_unpoison_object+0x82/0x110
[  981.289548]  __alloc_skb+0x2c3/0x8f0
[  981.289559]  napi_alloc_skb+0x58/0x220
[  981.289565]  igc_poll+0x400f/0x7660 [igc]
[  981.289604]  __napi_poll+0x91/0x380
[  981.289612]  net_rx_action+0x4e0/0xbc0
[  981.289620]  handle_softirqs+0x173/0x4d0
[  981.289630]  __irq_exit_rcu+0x63/0xd0
[  981.289639]  common_interrupt+0x81/0x90
[  981.289648]  asm_common_interrupt+0x26/0x40

[  981.289658] Freed by task 0:
[  981.289662]  kasan_save_track+0x3e/0x80
[  981.289671]  kasan_save_free_info+0x40/0x50
[  981.289678]  __kasan_slab_free+0x3a/0x60
[  981.289684]  kmem_cache_free+0xe9/0x370
[  981.289693]  br_stp_rcv+0x39a/0x1390
[  981.289701]  stp_pdu_rcv+0x227/0x370
[  981.289710]  llc_rcv+0x552/0x8d0
[  981.289718]  __netif_receive_skb_list_core+0x600/0x790
[  981.289726]  netif_receive_skb_list_internal+0x6f0/0x940
[  981.289734]  napi_complete_done+0x1a6/0x400
[  981.289741]  igc_poll+0x5c6d/0x7660 [igc]
[  981.289779]  __napi_poll+0x91/0x380
[  981.289786]  net_rx_action+0x4e0/0xbc0
[  981.289794]  handle_softirqs+0x173/0x4d0
[  981.289802]  __irq_exit_rcu+0x63/0xd0
[  981.289811]  common_interrupt+0x81/0x90
[  981.289819]  asm_common_interrupt+0x26/0x40

[  981.289828] The buggy address belongs to the object at ffff888201376f00
                which belongs to the cache skbuff_head_cache of size 224
[  981.289836] The buggy address is located 212 bytes inside of
                freed 224-byte region [ffff888201376f00, ffff888201376fe0)

[  981.289847] The buggy address belongs to the physical page:
[  981.289854] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x201376
[  981.289864] head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[  981.289870] flags: 0x100000000000040(head|node=0|zone=1)
[  981.289879] page_type: f5(slab)
[  981.289889] raw: 0100000000000040 ffff8881003437c0 dead000000000100 dead000000000122
[  981.289897] raw: 0000000000000000 0000000000190019 00000000f5000000 0000000000000000
[  981.289903] head: 0100000000000040 ffff8881003437c0 dead000000000100 dead000000000122
[  981.289909] head: 0000000000000000 0000000000190019 00000000f5000000 0000000000000000
[  981.289915] head: 0100000000000001 ffffffffffffff81 00000000ffffffff 00000000ffffffff
[  981.289920] head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[  981.289923] page dumped because: kasan: bad access detected

[  981.289930] Memory state around the buggy address:
[  981.289935]  ffff888201376e80: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc
[  981.289940]  ffff888201376f00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  981.289945] >ffff888201376f80: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
[  981.289948]                                                  ^
[  981.289953]  ffff888201377000: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
[  981.289957]  ffff888201377080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  981.289960] ==================================================================
[  981.289964] Disabling lock debugging due to kernel taint
[  981.289972] ------------[ cut here ]------------
[  981.289976] refcount_t: underflow; use-after-free.
[  981.289980] WARNING: at refcount_warn_saturate+0x84/0xd0, CPU#7: kworker/7:2/92
[  986.631187] Modules linked in: igc
[  986.672125] CPU: 7 UID: 0 PID: 92 Comm: kworker/7:2 Tainted: G    B   W           7.3.0-rc6+ #4 PREEMPT 
[  986.786934] Tainted: [B]=BAD_PAGE, [W]=WARN
[  986.837256] Workqueue: events igc_reset_task [igc]
[  986.895096] RIP: 0010:refcount_warn_saturate+0x84/0xd0
[  986.957010] Code: 74 2f 83 fb 01 75 38 48 8d 3d 1c 18 0b 03 67 48 0f b9 3a eb 36 48 8d 3d 1a 18 0b 03 67 48 0f b9 3a eb 28 48 8d 3d 18 18 0b 03 <67> 48 0f b9 3a eb 1a 48 8d 3d 16 18 0b 03 67 48 0f b9 3a eb 0c 48
[  987.182580] RSP: 0018:ffffc9000073faa0 EFLAGS: 00010246
[  987.246116] RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffffb7e3a117
[  987.331872] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffffffffbaeeb8ec
[  987.418053] RBP: ffffc900012b7440 R08: 0000000000000007 R09: 00000000fffffffb
[  987.503797] R10: dffffc0000000000 R11: ffffed104026edfa R12: ffff888204c57288
[  987.589959] R13: 000000000000e0e8 R14: ffff888201376fd4 R15: 0000000000000011
[  987.675711] FS:  0000000000000000(0000) GS:ffff888864da5000(0000) knlGS:0000000000000000
[  987.773233] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  987.843183] CR2: 00007dc52cee8781 CR3: 0000000113426001 CR4: 0000000000f70ef0
[  987.929069] PKRU: 55555554
[  987.961732] Call Trace:
[  987.991154]  <TASK>
[  988.016584]  igc_clean_tx_ring+0x24a/0xb40 [igc]
[  988.072122]  igc_down+0x7b1/0xc70 [igc]
[  988.118496]  igc_reinit_locked+0x5a/0x80 [igc]
[  988.172072]  igc_reset_task+0xca/0xd0 [igc]
[  988.222531]  process_scheduled_works+0x805/0xf10
[  988.278089]  worker_thread+0x8d2/0xc60
[  988.323413]  ? __schedule+0x1011/0x2330
[  988.369478]  kthread+0x2c9/0x3a0
[  988.408473]  ? __pfx_worker_thread+0x10/0x10
[  988.459993]  ? __pfx_kthread+0x10/0x10
[  988.505192]  ret_from_fork+0x14d/0x3f0
[  988.550284]  ? __pfx_kthread+0x10/0x10
[  988.595629]  ret_from_fork_asm+0x1a/0x30
[  988.642823]  </TASK>
[  988.669290] ---[ end trace 0000000000000000 ]---


[ 2138.124024] [Poison overwritten] 0xffff91bb928da594-0xffff91bb928da594 @offset=1428. First byte 0x6a instead of 0x6b
[ 2138.124040] =============================================================================
[ 2138.124044] BUG skbuff_head_cache (Tainted: G        W          ): Object corrupt
[ 2138.124049] -----------------------------------------------------------------------------

[ 2138.124051] Allocated in kmem_cache_alloc_bulk_noprof+0x8d/0x370 age=89089 cpu=4 pid=0
[ 2138.124068]  kmem_cache_alloc_bulk_noprof+0x8d/0x370
[ 2138.124075]  __alloc_skb+0x35c/0x3b0
[ 2138.124080]  napi_alloc_skb+0x4c/0x110
[ 2138.124083]  igc_poll+0xf1f/0x1c80 [igc]
[ 2138.124108]  __napi_poll+0x2f/0x190
[ 2138.124115]  net_rx_action+0x299/0x4c0
[ 2138.124121]  handle_softirqs+0xd1/0x2a0
[ 2138.124128]  do_softirq+0x4b/0x70
[ 2138.124132]  flush_smp_call_function_queue+0x43/0x60
[ 2138.124138]  do_idle+0x1b4/0x210
[ 2138.124145]  cpu_startup_entry+0x29/0x30
[ 2138.124150]  start_secondary+0x95/0xa0
[ 2138.124157]  common_startup_64+0x12c/0x147
[ 2138.124162] Freed in __tcf_kfree_skb_list+0x38/0xc0 age=84826 cpu=4 pid=0
[ 2138.124172]  __tcf_kfree_skb_list+0x38/0xc0
[ 2138.124177]  __dev_queue_xmit+0xbe1/0xf20
[ 2138.124181]  tcf_mirred_to_dev+0x41c/0x4a0
[ 2138.124187]  tcf_mirred_act+0x30f/0x670
[ 2138.124192]  tcf_action_exec+0x95/0x220
[ 2138.124196]  tcf_classify+0x8e/0x200
[ 2138.124202]  tc_run+0xc7/0x120
[ 2138.124207]  __netif_receive_skb_core+0x4d5/0xc60
[ 2138.124212]  __netif_receive_skb_list_core+0xbc/0x290
[ 2138.124217]  netif_receive_skb_list_internal+0x178/0x2e0
[ 2138.124222]  napi_complete_done+0x99/0x150
[ 2138.124226]  igc_poll+0x16da/0x1c80 [igc]
[ 2138.124246]  __napi_poll+0x2f/0x190
[ 2138.124251]  net_rx_action+0x299/0x4c0
[ 2138.124256]  handle_softirqs+0xd1/0x2a0
[ 2138.124261]  __irq_exit_rcu+0x44/0xa0
[ 2138.124265] Slab 0xffffd132cb4a3680 objects=21 used=19 fp=0xffff91bb928db9c0 flags=0x100000000000240(workingset|head|node=0|zone=1)
[ 2138.124274] Object 0xffff91bb928da4c0 @offset=1216 fp=0xffff91bb928db9c0

[ 2138.124278] Redzone  ffff91bb928da480: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb  ................
[ 2138.124282] Redzone  ffff91bb928da490: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb  ................
[ 2138.124284] Redzone  ffff91bb928da4a0: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb  ................
[ 2138.124286] Redzone  ffff91bb928da4b0: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb  ................
[ 2138.124289] Object   ffff91bb928da4c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[ 2138.124291] Object   ffff91bb928da4d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[ 2138.124293] Object   ffff91bb928da4e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[ 2138.124295] Object   ffff91bb928da4f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[ 2138.124297] Object   ffff91bb928da500: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[ 2138.124299] Object   ffff91bb928da510: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[ 2138.124301] Object   ffff91bb928da520: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[ 2138.124302] Object   ffff91bb928da530: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[ 2138.124304] Object   ffff91bb928da540: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[ 2138.124306] Object   ffff91bb928da550: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[ 2138.124308] Object   ffff91bb928da560: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[ 2138.124309] Object   ffff91bb928da570: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[ 2138.124311] Object   ffff91bb928da580: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[ 2138.124313] Object   ffff91bb928da590: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  kkkkjkkkkkkkkkk.
[ 2138.124315] Redzone  ffff91bb928da5a0: bb bb bb bb bb bb bb bb                          ........
[ 2138.124317] Padding  ffff91bb928da5f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
[ 2138.124320] Disabling lock debugging due to kernel taint
[ 2138.124337] ------------[ cut here ]------------
[ 2138.124339] WARNING: at object_err+0xa7/0xd0, CPU#6: swapper/6/0
[ 2138.124375] Modules linked in: igc
[ 2138.124385] CPU: 6 UID: 0 PID: 0 Comm: swapper/6 Tainted: G    B   W           7.3.0-rc6-nokasan+ #5 PREEMPT 
[ 2138.124394] Tainted: [B]=BAD_PAGE, [W]=WARN
[ 2138.124398] RIP: 0010:object_err+0xa7/0xd0
[ 2138.124403] Code: 85 d2 74 3d 4c 89 f7 e8 87 fe ff ff 48 c7 c7 0b 28 d7 8b 48 89 de e8 e8 cf ff ff bf 05 00 00 00 be 01 00 00 00 e8 99 ae 12 00 <0f> 0b 5b 41 5e 41 5f c3 cc cc cc cc cc 48 99 48 f7 fe 48 85 d2 75
[ 2138.124408] RSP: 0018:ffffab8bc02f4a30 EFLAGS: 00010046
[ 2138.124414] RAX: 0000000000000000 RBX: ffff91bb928da4c0 RCX: f49708951d977900
[ 2138.124418] RDX: 3fffffffffffdfff RSI: 0000000000000000 RDI: 0000000000000005
[ 2138.124422] RBP: ffff91b9c0b967c0 R08: 0000000000001fff R09: ffffffff8c45c8f0
[ 2138.124425] R10: 0000000000005ffd R11: ffffffff8c45c8f0 R12: ffffffff8bd8ed9a
[ 2138.124429] R13: ffff91bb928da594 R14: ffffd132cb4a3680 R15: ffff91b9c0b967c0
[ 2138.124431] FS:  0000000000000000(0000) GS:ffff91c192d95000(0000) knlGS:0000000000000000
[ 2138.124436] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2138.124440] CR2: 0000000000e9ac50 CR3: 0000000150f91005 CR4: 0000000000f70ef0
[ 2138.124444] PKRU: 55555554
[ 2138.124447] Call Trace:
[ 2138.124450]  <IRQ>
[ 2138.124453]  check_bytes_and_report+0xea/0x110
[ 2138.124461]  check_object+0x131/0x360
[ 2138.124467]  alloc_debug_processing+0xaf/0x1a0
[ 2138.124472]  get_from_partial_node+0x11c/0x410
[ 2138.124478]  ___slab_alloc+0xad/0x760
[ 2138.124484]  __kmem_cache_alloc_bulk+0x13c/0x190
[ 2138.124490]  ? kmem_cache_alloc_bulk_noprof+0x8d/0x370
[ 2138.124499]  kmem_cache_alloc_bulk_noprof+0x8d/0x370
[ 2138.124506]  __alloc_skb+0x35c/0x3b0
[ 2138.124511]  napi_alloc_skb+0x4c/0x110
[ 2138.124514]  igc_poll+0xf1f/0x1c80 [igc]
[ 2138.124538]  __napi_poll+0x2f/0x190
[ 2138.124544]  net_rx_action+0x299/0x4c0
[ 2138.124552]  handle_softirqs+0xd1/0x2a0
[ 2138.124559]  __irq_exit_rcu+0x44/0xa0
[ 2138.124564]  common_interrupt+0x81/0x90
[ 2138.124570]  </IRQ>
[ 2138.124571]  <TASK>
[ 2138.124574]  asm_common_interrupt+0x26/0x40
[ 2138.124578] RIP: 0010:mwait_idle+0x49/0x60
[ 2138.124586] Code: 80 0e 40 48 f7 06 10 00 00 00 75 1f 48 89 f0 0f 1f 00 31 c9 31 d2 0f 01 c8 48 f7 06 10 00 00 00 75 09 31 c0 31 c9 fb 0f 01 c9 <fa> f0 80 26 bf c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
[ 2138.124590] RSP: 0018:ffffab8bc01abef8 EFLAGS: 00000246
[ 2138.124594] RAX: 0000000000000000 RBX: ffffab8bc01abf0f RCX: 0000000000000000
[ 2138.124597] RDX: 0000000000000000 RSI: ffff91b9c0959080 RDI: 000000000066674c
[ 2138.124600] RBP: 0000000000000000 R08: 0000000000000402 R09: 0000000000001c00
[ 2138.124603] R10: 0000000000000000 R11: ffffffff8a78a5e0 R12: ffff91b9c0959080
[ 2138.124605] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 2138.124609]  ? __pfx_set_next_task_idle+0x10/0x10
[ 2138.124619]  default_idle_call+0x39/0x60
[ 2138.124626]  do_idle+0xbd/0x210
[ 2138.124632]  cpu_startup_entry+0x29/0x30
[ 2138.124639]  start_secondary+0x95/0xa0
[ 2138.124645]  common_startup_64+0x12c/0x147
[ 2138.124652]  </TASK>
[ 2138.124654] ---[ end trace 0000000000000000 ]---





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2026-10-14  5:43 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-13  1:09 [PATCH net v2] igc: only strip RX timestamp header from first buffer Paul Moses
2026-10-13  1:15 ` netdev-bot+sinfo
2026-10-14  1:10 ` sashiko-bot
2026-10-14  1:40   ` Paul Moses
2026-10-14  1:55     ` Paul Moses
2026-10-14  1:59 ` netdev-bot+sashiko
2026-10-14  5:43   ` Paul Moses

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.