KCSAN: data-race in e1000_clean / e1000_xmit_frame

["Jianzhou Zhao" <luckd0g@163.com>]

Subject: [BUG] e1000: KCSAN: data-race in e1000_clean_tx_irq / e1000_tso

Dear Maintainers,

We are writing to report a KCSAN-detected data race vulnerability within the `e1000` network driver. This bug was found by our custom fuzzing tool, RacePilot. The race occurs when `e1000_tso()` writes a new `next_to_watch` tracking array index for a transmission buffer without volatile locking, while the `e1000_clean_tx_irq()` subroutine locklessly evaluates this field concurrently. We observed this bug on the Linux kernel version 6.18.0-08691-g2061f18ad76e-dirty.

Call Trace & Context
==================================================================
BUG: KCSAN: data-race in e1000_clean / e1000_xmit_frame

write to 0xffffc9000414e492 of 2 bytes by task 5500 on cpu 0:
 e1000_tso drivers/net/ethernet/intel/e1000/e1000_main.c:2752 [inline]
 e1000_xmit_frame+0x14fe/0x2a90 drivers/net/ethernet/intel/e1000/e1000_main.c:3226
 __netdev_start_xmit include/linux/netdevice.h:5273 [inline]
 netdev_start_xmit include/linux/netdevice.h:5282 [inline]
 xmit_one net/core/dev.c:3853 [inline]
 dev_hard_start_xmit+0xee/0x3a0 net/core/dev.c:3869
 ...
 tcp_write_xmit+0xf64/0x3ee0 net/ipv4/tcp_output.c:3002
 tcp_push_one+0x87/0xa0 net/ipv4/tcp_output.c:3199
 
read to 0xffffc9000414e492 of 2 bytes by interrupt on cpu 1:
 e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3871 [inline]
 e1000_clean+0x2fb/0x1570 drivers/net/ethernet/intel/e1000/e1000_main.c:3804
 __napi_poll+0x5d/0x3f0 net/core/dev.c:7666
 napi_poll net/core/dev.c:7729 [inline]
 net_rx_action+0x6cc/0x890 net/core/dev.c:7881
 handle_softirqs+0xbe/0x290 kernel/softirq.c:622
 ...

value changed: 0x0083 -> 0x008d

Reported by Kernel Concurrency Sanitizer on:
CPU: 1 UID: 0 PID: 194865 Comm: syz.3.8279 Not tainted 6.18.0-08691-g2061f18ad76e-dirty #44 PREEMPT(voluntary) 
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
==================================================================

Execution Flow & Code Context
During standard outgoing network transactions over the `e1000` queue layout, `e1000_tso` maps buffer parameters into descriptions and sets `buffer_info->next_to_watch`:
```c
// drivers/net/ethernet/intel/e1000/e1000_main.c
static int e1000_tso(struct e1000_adapter *adapter,
		     struct e1000_tx_ring *tx_ring, struct sk_buff *skb,
		     __be16 protocol)
{
	...
		context_desc->cmd_and_length = cpu_to_le32(cmd_length);

		buffer_info->time_stamp = jiffies;
		buffer_info->next_to_watch = i; // <-- Concurrent 2-byte lockless write

		if (++i == tx_ring->count)
			i = 0;
	...
}
```

Simultaneously, `e1000_clean_tx_irq()` operates from IRQ/NAPI loops tracking trailing descriptor completion, directly reading `next_to_watch` from active bounds before evaluating the hardware completion marker bit:
```c
// drivers/net/ethernet/intel/e1000/e1000_main.c
static bool e1000_clean_tx_irq(struct e1000_adapter *adapter,
			       struct e1000_tx_ring *tx_ring)
{
	...
	i = tx_ring->next_to_clean;
	eop = tx_ring->buffer_info[i].next_to_watch; // <-- Concurrent 2-byte lockless read
	eop_desc = E1000_TX_DESC(*tx_ring, eop);

	while ((eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) &&
	...
```

Root Cause Analysis
A KCSAN data race arises because `e1000_clean_tx_irq()` fetches `next_to_watch` before examining the transmit completion synchronization `E1000_TXD_STAT_DD` bit asynchronously across independent core cycles. This inherently causes collision overlaps against background `e1000_xmit_frame` calls queuing buffers onto identical arrays during transmission pipelines. While logical structures inherently mask off processing loops if the `DD` bit defaults logically, unpredictable compiler caching causes unoptimized structure tearing.
Unfortunately, we were unable to generate a reproducer for this bug.

Potential Impact
This data race presents theoretical local memory corruption or networking state breakdown risks alongside constant KCSAN performance degradation if a compiler incorrectly infers visibility assumptions across unannotated variables bridging hardware transmission synchronizations. 

Proposed Fix
Implementing `READ_ONCE()` and `WRITE_ONCE()` bounds around `next_to_watch` resolves the data race logically, ensuring correct load barriers on NAPI consumers:

```diff
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -2749,7 +2749,7 @@ static int e1000_tso(struct e1000_adapter *adapter,
 		context_desc->cmd_and_length = cpu_to_le32(cmd_length);
 
 		buffer_info->time_stamp = jiffies;
-		buffer_info->next_to_watch = i;
+		WRITE_ONCE(buffer_info->next_to_watch, i);
 
 		if (++i == tx_ring->count)
 			i = 0;
@@ -3839,7 +3839,7 @@ static bool e1000_clean_tx_irq(struct e1000_adapter *adapter,
 	unsigned int bytes_compl = 0, pkts_compl = 0;
 
 	i = tx_ring->next_to_clean;
-	eop = tx_ring->buffer_info[i].next_to_watch;
+	eop = READ_ONCE(tx_ring->buffer_info[i].next_to_watch);
 	eop_desc = E1000_TX_DESC(*tx_ring, eop);
 
 	while ((eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) &&
```
*(Note: Similar `WRITE_ONCE` bounds should also be applied to `e1000_tx_map` and `e1000_tx_csum` respectively)*

We would be highly honored if this could be of any help.

Best regards,
RacePilot Team