Hi all,
I would like to add a separate Intel X550 / ixgbe crash report on 7.0.14-20-pve. This differs from the recent Broadcom / bnxt_en reports in this thread.
We captured the full crash through pstore, which identifies the failing function as ixgbe_check_mdd_event().
Environment
ixgbe 0000:61:00.0: Malicious event on VF 8 tx:80000 rx:0
ixgbe 0000:61:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0004 address=0xd5b294c0 flags=0x0000]
BUG: kernel NULL pointer dereference, address: 000000000000078c
#PF: supervisor write access in kernel mode
Relevant pstore excerpt
Oops: Oops: 0002 [#1] SMP NOPTI
CPU: 5 UID: 0 PID: 0 Comm: swapper/5 Tainted: P O 7.0.14-20-pve #1 PREEMPT(lazy)
Hardware name: Supermicro Super Server/H11DSi-NT, BIOS 2.1 02/21/2020
RIP: 0010:ixgbe_check_mdd_event+0x124/0x160 [ixgbe]
RAX: 0000000000000740 RBX: 0000000000000008 RCX: 0000000000000008
CR2: 000000000000078c
The IRQ call chain includes:
ixgbe_check_mdd_event
ixgbe_msg_task
ixgbe_msix_other
__handle_irq_event_percpu
handle_irq_event
handle_edge_irq
__common_interrupt
common_interrupt
Followed by:
Kernel panic - not syncing: Fatal exception in interrupt
The host became completely unresponsive and required a reboot.
No SR-IOV VFs configured
The following was checked after reboot:
cat /sys/class/net/eno1/device/sriov_numvfs
0
The private flags are:
legacy-rx : off
vf-ipsec : off
mdd-disable-vf: off
This appears consistent with the reported issue where an MDD event causes access to adapter->vfinfo[] despite no VFs being configured. The stacktrace confirms the crash location; we have not established what triggered the MDD event or the accompanying IOMMU fault.
Potentially related reports:
We have installed 6.17.13-21-pve in preparation for a comparison test. We do not yet have a stability result and cannot claim that it fixes this issue.
The X550 interfaces are required for our infrastructure, so bypassing these NICs is not a practical workaround.
Could the Proxmox team confirm:
I would like to add a separate Intel X550 / ixgbe crash report on 7.0.14-20-pve. This differs from the recent Broadcom / bnxt_en reports in this thread.
We captured the full crash through pstore, which identifies the failing function as ixgbe_check_mdd_event().
Environment
- Proxmox VE manager: 9.2.21
- Kernel at the time of the crash: 7.0.14-20-pve
- Mainboard: Supermicro H11DSi-NT
- BIOS: 2.1, dated 2020-02-21
- NIC: Intel X550 [8086:1563], revision 01
- Subsystem: Supermicro [15d9:1563]
- Driver: in-tree ixgbe
- NIC firmware reported by ethtool: 0x800007f3, 1.1276.0
- Affected interface: eno1, PCI address 0000:61:00.0
- Interface used as a bridge uplink for VM traffic, with VLAN subinterfaces
- Link: 10 Gbit/s
ixgbe 0000:61:00.0: Malicious event on VF 8 tx:80000 rx:0
ixgbe 0000:61:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0004 address=0xd5b294c0 flags=0x0000]
BUG: kernel NULL pointer dereference, address: 000000000000078c
#PF: supervisor write access in kernel mode
Relevant pstore excerpt
Oops: Oops: 0002 [#1] SMP NOPTI
CPU: 5 UID: 0 PID: 0 Comm: swapper/5 Tainted: P O 7.0.14-20-pve #1 PREEMPT(lazy)
Hardware name: Supermicro Super Server/H11DSi-NT, BIOS 2.1 02/21/2020
RIP: 0010:ixgbe_check_mdd_event+0x124/0x160 [ixgbe]
RAX: 0000000000000740 RBX: 0000000000000008 RCX: 0000000000000008
CR2: 000000000000078c
The IRQ call chain includes:
ixgbe_check_mdd_event
ixgbe_msg_task
ixgbe_msix_other
__handle_irq_event_percpu
handle_irq_event
handle_edge_irq
__common_interrupt
common_interrupt
Followed by:
Kernel panic - not syncing: Fatal exception in interrupt
The host became completely unresponsive and required a reboot.
No SR-IOV VFs configured
The following was checked after reboot:
cat /sys/class/net/eno1/device/sriov_numvfs
0
The private flags are:
legacy-rx : off
vf-ipsec : off
mdd-disable-vf: off
This appears consistent with the reported issue where an MDD event causes access to adapter->vfinfo[] despite no VFs being configured. The stacktrace confirms the crash location; we have not established what triggered the MDD event or the accompanying IOMMU fault.
Potentially related reports:
- https://bugzilla.proxmox.com/show_bug.cgi?id=7874
- https://lists.openwall.net/netdev/2026/02/28/15
- https://marc.info/?l=intel-wired-lan&m=178600755017811&w=3
We have installed 6.17.13-21-pve in preparation for a comparison test. We do not yet have a stability result and cannot claim that it fixes this issue.
The X550 interfaces are required for our infrastructure, so bypassing these NICs is not a practical workaround.
Could the Proxmox team confirm:
- Whether 6.17.13-21-pve contains the same unguarded MDD/VF access path.
- Whether a fix or backport is planned for the 7.0 kernel series, and which build should contain it.
- Whether there is a validated workaround for systems with sriov_numvfs=0 while retaining the X550 interfaces.