OFED backport of mainline mlx5e XSK stale-buffer-release fix (kernel panic in mlx5e_post_rx_wqes)

Infrastructure & Networking Software And Drivers Mellanox OFED
,
1

Hi,

We hit a kernel panic on AF_XDP zero-copy RX with the out-of-tree mlx5_core from OFED. Upstream Linux has a fix that looks like the same bug. Can you confirm whether it’s going to be fixed soon? We use the newest version doca-3.5.0 and it still there.

Environment

  • Kernel: 7.0.0-30-generic (Ubuntu)

  • Driver: out-of-tree mlx5_core (tainted OE — unsigned OOT module)

  • OFED / MLNX_OFED version: 3.5.0
    driver: mlx5_core
    version: 2607.0.100
    firmware-version: 22.47.1026 (MT_0000000359)

    filename: /lib/modules/7.0.0-34-generic/updates/dkms/mlx5_core.ko.zst
    version: 2607.0.100
    srcversion: 8BBA768CA4D3A1FA2A16C01
    vermagic: 7.0.0-34-generic SMP preempt mod_unload modversions

  • Workload: AF_XDP zero-copy (DRV mode), high-rate RX, userspace fill/completion rings

    Panic (kdump)

    BUG: kernel NULL pointer dereference, address: 0000000000000034
Oops: 0000 [#1] SMP PTI
CPU: 0 PID: 14 Comm: ksoftirqd/0 Tainted: G OE  7.0.0-30-generic
RIP: 0010:mlx5e_post_rx_wqes+0xe0/0x4e0 [mlx5_core]
Call Trace:
  mlx5e_napi_poll
  __napi_poll
  net_rx_action
  handle_softirqs
  run_ksoftirqd

    Upstream fix we believe applies:

    [v3] net/mlx5e: Prevent stale XSK buffer release on refill retries | Patchew

    Merged to mainline (net) around 2026-09-04:

    • net/mlx5e: Prevent stale XSK buffer release on refill retry
    • net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry

    If XDP redirect to an AF_XDP socket fails because the RX ring is full, the XSK core already frees the buffer. On a later batched RQ refill, mlx5e can free the same WQE buffer again through a stale pointer, then publish that UMEM frame twice. The next mlx5e_post_rx_wqes can then NULL-deref (our crash) or silently corrupt buffers (depends on Stride RQ is ON or OFF).

Thanks,
Marcin

2

Hi Marcin,

I authored the two upstream fixes referenced above:

The stale-buffer release mechanism you describe is precisely what this series addresses. However, I have not reproduced your OFED panic, so the stack trace alone does not confirm that it has the same root cause.

Could NVIDIA confirm whether these fixes are included in driver 2607.0.100, and whether a backport is planned if they are missing?

Thanks, Jérôme