In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: xsk: Fix DMA and xdpframe leak on XDPTX xmit failure

In the XSK branch of mlx5exmitxdpbuff(), when sq->xmitxdpframe() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdpframe allocated by xdpconvertzctoxdpframe(). The xdpififo push only happens on success, so the completion path cannot recover these entries.

With CONFIGDMAAPIDEBUG=y, the leak surfaces on driver unbind:

DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMATODEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dmadebugdevicechange+0x127/0x180 ... DMA-API: Mapped at: debugdmamapphys+0x4b/0xd0 dmamapphys+0xfd/0x2d0 mlx5exdphandle+0x5ae/0xac0 [mlx5core] mlx5exskskbfromcqempwrqlinear+0xc4/0x170 [mlx5core] mlx5ehandlerxcqempwrq+0xc1/0x290 [mlx5core]

Add the missing unmap + xdpreturnframe, matching the cleanup already done in mlx5exdpxmit(). hasfrags is rejected earlier in this branch, so no per-frag unmap is needed.

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Fix deadlocks between devlink and netdev instance locks

In the mentioned "Fixes" commit, various work tasks triggering devlink health reporter recovery were switched to use netdevtrylock to protect against concurrent tear down of the channels being recovered. But this had the side effect of introducing potential deadlocks because of incorrect lock ordering.

The correct lock order is described by the init flow: probeone -> mlx5initone (acquires devlink lock) -> mlx5initonedevllocked -> mlx5registerdevice -> mlx5rescandriverslocked -...-> mlx5eprobe -> mlx5eprobe -> registernetdev (acquires rtnl lock) -> registernetdevice (acquires netdev lock) => devlink lock -> rtnl lock -> netdev lock.

But in the current recovery flow, the order is wrong: mlx5etxerrcqework (acquires netdev lock) -> mlx5ereportertxerrcqe -> mlx5ehealthreport -> devlinkhealthreport (acquires devlink lock => boom!) -> devlinkhealthreporterrecover -> mlx5etxreporterrecover -> mlx5etxreporterrecoverfromctx -> mlx5etxreportererrcqerecover

The same pattern exists in: mlx5ereporterrxtimeout mlx5ereportertxptpsqunhealthy mlx5ereportertxtimeout

Fix these by moving the netdevtrylock calls from the work handlers lower in the call stack, in the respective recovery functions, where they are actually necessary.

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery

In case of a TX error CQE, a recovery flow is triggered, mlx5eresettxqsqccpc() resets dmafifocc to 0 but not dmafifopc, desyncing the DMA FIFO producer and consumer.

After recovery, the producer pushes new DMA entries at the old dmafifopc, while the consumer reads from position 0. This causes us to unmap stale DMA addresses from before the recovery.

The DMA FIFO is a purely software construct with no HW counterpart. At the point of reset, all WQEs have been flushed so dmafifocc is already equal to dmafifopc. There is no need to reset either counter, similar to how skbfifo pc/cc are untouched.

Remove the 'dmafifocc = 0' reset.

This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommudmaunmappage+0x79/0x90 Modules linked in: mlx5vdpa vringh vdpa bonding mlx5ib mlx5vfiopci ipip mlx5fwctl tunnel4 mlx5core ibipoib geneve ip6gre ipgre gre nftables ip6tunnel rdmaucm ibuverbs ibumad vfiopci vfiopcicore actmirred actskbedit actvlan vhostnet vhost tap ip6tablemangle ip6tablenat ip6tablefilter ip6tables iptablemangle clsmatchall nfnetlinkcttimeout actgact clsflower schingress vhostiotlb iptableraw tunnel6 vfioiommutype1 vfio openvswitch nsh rpcsecgsskrb5 authrpcgss oidregistry xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink iptablenat nfnat xtaddrtype brnetfilter overlay zram zsmalloc rpcrdma ibiser libiscsi scsitransportiscsi rdmacm iwcm ibcm ibcore fuse [last unloaded: nftables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5forupstreammindebug202412302133 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommudmaunmappage+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: <IRQ> ? warn+0x7d/0x110 ? iommudmaunmappage+0x79/0x90 ? reportbug+0x16d/0x180 ? handlebug+0x4f/0x90 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 ? iommudmaunmappage+0x79/0x90 ? iommudmaunmappage+0x2e/0x90 dmaunmappageattrs+0x10d/0x1b0 mlx5etxwidmaunmap+0xbe/0x120 [mlx5core] mlx5epolltxcq+0x16d/0x690 [mlx5core] mlx5enapipoll+0x8b/0xac0 [mlx5core] napipoll+0x24/0x190 netrxaction+0x32a/0x3b0 ? mlx5eqcompint+0x7e/0x270 [mlx5core] ? notifiercallchain+0x35/0xa0 handlesoftirqs+0xc9/0x270 irqexitrcu+0x71/0xd0 commoninterrupt+0x7f/0xa0 </IRQ> <TASK> asmcommoninterrupt+0x22/0x40

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Fix race condition during IPSec ESN update

In IPSec full offload mode, the device reports an ESN (Extended Sequence Number) wrap event to the driver. The driver validates this event by querying the IPSec ASO and checking that the esneventarm field is 0x0, which indicates an event has occurred. After handling the event, the driver must re-arm the context by setting esneventarm back to 0x1.

A race condition exists in this handling path. After validating the event, the driver calls mlx5accelespmodifyxfrm() to update the kernel's xfrm state. This function temporarily releases and re-acquires the xfrm state lock.

So, need to acknowledge the event first by setting esneventarm to 0x1. This prevents the driver from reprocessing the same ESN update if the hardware sends events for other reason. Since the next ESN update only occurs after nearly 2^31 packets are received, there's no risk of missing an update, as it will happen long after this handling has finished.

Processing the event twice causes the ESN high-order bits (esnmsb) to be incremented incorrectly. The driver then programs the hardware with this invalid ESN state, which leads to anti-replay failures and a complete halt of IPSec traffic.

Fix this by re-arming the ESN event immediately after it is validated, before calling mlx5accelespmodifyxfrm(). This ensures that any spurious, duplicate events are correctly ignored, closing the race window.

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: RX, Fix generating skb from non-linear xdpbuff for striding RQ

XDP programs can change the layout of an xdpbuff through bpfxdpadjusttail() and bpfxdpadjusthead(). Therefore, the driver cannot assume the size of the linear data area nor fragments. Fix the bug in mlx5 by generating skb according to xdpbuff after XDP programs run.

Currently, when handling multi-buf XDP, the mlx5 driver assumes the layout of an xdpbuff to be unchanged. That is, the linear data area continues to be empty and fragments remain the same. This may cause the driver to generate erroneous skb or triggering a kernel warning. When an XDP program added linear data through bpfxdpadjusthead(), the linear data will be ignored as mlx5ebuildlinearskb() builds an skb without linear data and then pull data from fragments to fill the linear data area. When an XDP program has shrunk the non-linear data through bpfxdpadjusttail(), the delta passed to pskbpulltail() may exceed the actual nonlinear data size and trigger the BUGON in it.

To fix the issue, first record the original number of fragments. If the number of fragments changes after the XDP program runs, rewind the end fragment pointer by the difference and recalculate the truesize. Then, build the skb with the linear data area matching the xdpbuff. Finally, only pull data in if there is non-linear data and fill the linear part up to 256 bytes.