I'm hitting the bug daily with Intel X550.
please be informed, i may provide kernel dumps on request.
## One-line
On an Intel X550 with **no VFs configured** (`sriov_numvfs=0`), a
spurious MDD interrupt reaches `ixgbe_check_mdd_event()`, which writes
into `adapter->vfinfo[]` without guarding for `num_vfs==0` — and
`vfinfo` is NULL when SR-IOV is off → kernel panic in interrupt context.
Reproduces roughly once a day under normal operation.
## Environment
- Kernel: **7.0.0-28-generic #28-Ubuntu** (PREEMPT lazy), x86_64
- Driver: **ixgbe** (in-tree), with the new "support Malicious Driver
Detection (MDD)" series
- NIC: **Intel X550** (`enp169s0f1`), link at 100 Mb/s
- Board: ASRock Rack TURIND8UD-2T/X550, BIOS 10.05 (2025-06-19)
- CPU: AMD EPYC 9135 (Zen5)
- **SR-IOV: disabled** —
`/sys/class/net/enp169s0f{0,1}/device/sriov_numvfs = 0` (totalvfs=63),
no VF PCI functions present
## Symptom
Kernel panic, ~once every 12–51h, always in interrupt context on an
otherwise-idle CPU (`swapper/N`). 5 occurrences captured via kdump
(2026-07-28 … 2026-08-03).
```
BUG: kernel NULL pointer dereference, address: 00000000000005bc (also
seen: 0xa44)
#PF: supervisor write access in kernel mode
Oops: 0002 [#1] SMP NOPTI
CPU: 16 UID: 0 PID: 0 Comm: swapper/16 Not tainted 7.0.0-28-generic
#28-Ubuntu
Hardware name: TURIND8UD-2T/X550, BIOS 10.05 06/19/2025
RIP: 0010:ixgbe_check_mdd_event+0x141/0x180 [ixgbe]
Call Trace:
ixgbe_msg_task+0x2a/0x140 [ixgbe]
ixgbe_msix_other+0x1cf/0x280 [ixgbe]
__handle_irq_event_percpu+0x59/0x230
handle_irq_event+0x36/0x80
handle_edge_irq+0xd3/0x1a0
__common_interrupt+0x50/0x160
common_interrupt+0xb0/0xe0
(interrupted cpuidle_enter_state — CPU was idle)
Kernel panic - not syncing: Fatal exception in interrupt
```
## Root-cause analysis
- `ixgbe_msg_task()` calls `ixgbe_check_mdd_event(adapter)`
**unconditionally**.
- `ixgbe_check_mdd_event()` writes `adapter->vfinfo[i].clear_to_send =
0;` with **no check for `adapter->num_vfs`** and no NULL-check on
`adapter->vfinfo`.
- `adapter->vfinfo` is only allocated when SR-IOV is enabled; with
`num_vfs==0` it is **NULL**.
- The fault is a **write** (`Oops 0002`) to a small address (0x5bc /
0xa44 = offsets within a `struct vf_data_storage`), consistent with
`&vfinfo[i].
- The code appears to assume `hw->mac.ops.handle_mdd` returns an empty
bitmap when no VFs exist; on this hardware an MDD "other" MSI-X
interrupt is delivered anyway, so the loop runs and dereferences NULL.
## Suggested fix
Guard MDD-event handling on SR-IOV being active — e.g. early-return from
`ixgbe_check_mdd_event()` (and/or skip the call in `ixgbe_msg_task()`)
when `adapter->num_vfs == 0` or `adapter->vfinfo == NULL`.
## Reproduction
Intel X550 + kernel 7.0.0-28 with SR-IOV disabled (0 VFs); occurs during
normal operation (no VF workload), interrupt-driven, ~daily. Not
load-correlated (hits idle CPUs).
## Available on request
5 kdump vmcores + full `dmesg.*` per crash.
## Related upstream work — checked against mainline, does NOT fix this
A recent patch — **"ixgbe: only access vfinfo and mv_list under RCU
lock"** (netdev, 2026-05-13, `Fixes: 1e53834ce541d` = "ixgbe: Add
locking to prevent panic when setting sriov_numvfs to zero") — fixes a
use-after-free *race* where `ixgbe_disable_sriov()` frees
`adapter->vfinfo` while `ixgbe_msg_task()` runs, i.e. **toggling
`sriov_numvfs`**.
**Verified against current `torvalds/linux` master (`ixgbe_sriov.c`):
the present bug is still unfixed.** `ixgbe_check_mdd_event()` writes
`adapter->vfinfo[i]` with no `num_vfs`/NULL guard, and
`ixgbe_msg_task()` calls it unconditionally:
```c
bool ixgbe_check_mdd_event(struct ixgbe_adapter *adapter)
{
...
if (!hw->mac.ops.handle_mdd)
return false;
hw->mac.ops.handle_mdd(hw, vf_bitmap); /* HW can set bits
with num_vfs==0 */
for_each_set_bit(i, vf_bitmap, 64) {
...
if (hw->mac.ops.restore_mdd_vf) {
...
adapter->vfinfo[i].clear_to_send = 0; /* vfinfo == NULL
when SR-IOV off -> NULL write */
...
}
}
}
```
This is a **distinct, still-unfixed bug** from the toggle-race: SR-IOV
is *never* enabled here (`num_vfs` stays 0), so `vfinfo` was never
allocated. The X550 raises an MDD event anyway, `handle_mdd()` sets a
bit, and the unguarded loop writes through NULL. **A kernel upgrade does
not fix it** — the buggy path is present in the latest tree.
Reviewed the following prior/related work — **none guard the
steady-state `num_vfs==0` MDD path**:
- "ixgbe: support Malicious Driver Detection (MDD)" series (iwl-next
v1–v3) — *introduced* `ixgbe_check_mdd_event()`; no `num_vfs` guard.
- `1e53834ce541d` "ixgbe: Add locking to prevent panic when setting
sriov_numvfs to zero" — guards the *transition to zero*, not
steady-state zero.
- "ixgbe: only access vfinfo and mv_list under RCU lock" (net,
2026-05-13) — fixes the free-vs-use *race* on `vfinfo`; does not add a
`num_vfs==0`/NULL guard.
- `torvalds/linux` master
`drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c` (verified 2026-08) —
`ixgbe_check_mdd_event()` still writes `adapter->vfinfo[i]` unguarded.
--
Best Regards,
V
