ESXi Host Encounters a PSOD when Using DFW with IDPS Slowpath Traffic

Products

• VMware vDefend Firewall

Issue/Introduction

ESXi hosts may experience a PSOD leading to an unexpected host crash in environments running Distributed Firewall (DFW) and Intrusion Detection and Prevention System (IDPS) rules where traffic is redirected to the slowpath. The PSOD backtrace typically involves Pkt_AttrObjAlloc, Pkt_AttrCreateAndSet, and FC_FlowAttrSet or VSIPDVFProcessPacketsInt.

Backtrace:

(gdb) bt
#0  FastSlab_Alloc (cache=<optimized out>) at <masked_path>/fastslab_public.h:320
#1  Pkt_AttrObjAlloc (size=<optimized out>, attrAllocType=<optimized out>) at <masked_path>/pktattr.c:497
#2  ##### in Pkt_AttrCreateAndSet (pkt=#####, attrHandle=attrHandle@entry=#####, value=value@entry=#####)
    at <masked_path>/pktattr.c:1569
#3  ##### in vmk_PktAttrCreateAndSet (pkt=<optimized out>, attrHandle=attrHandle@entry=#####, value=value@entry=#####)
    at <masked_path>/vmkapi_net_pkt.c:1609
#4  ##### in FC_FlowPktAttrSet (feAttr=#####, attrHandle=#####, pkt=<optimized out>) at datapath/esx/modules/fc/fc.c:172
#5  FC_FlowAttrSet (fcPkt=#####, fkey=<optimized out>, fc=#####) at datapath/esx/modules/fc/fc.c:1821
#6  ##### in FC_FlowLookupOrAttrSet (portID=portID@entry=<masked_portID>, fcPkt=fcPkt@entry=#####, fkey=fkey@entry=#####, 
    fc=fc@entry=#####, fe=fe@entry=#####, fcFlowAttrSetThrottle=fcFlowAttrSetThrottle@entry=0 '\000') at datapath/esx/modules/fc/fc.c:1862
#7  ##### in FC_LookupInput (portID=<optimized out>, arg=..., pktList=pktList@entry=#####, iocHandle=iocHandle@entry=#####)
    at datapath/esx/modules/fc/fc_datapath.c:2450
#8  ##### in IOChain_Resume (port=port@entry=#####, chain=chain@entry=#####, prevLink=prevLink@entry=0x0, 
    pktList=pktList@entry=#####, remainingPktList=remainingPktList@entry=0x0) at <masked_path>/iochain.c:991
#9  ##### in Port_InputResume (port=port@entry=#####, prev=prev@entry=0x0, pktList=pktList@entry=#####)
    at <masked_path>/port.c:4223
#10 ##### in Port_Input (port=port@entry=#####, pktList=pktList@entry=#####) at <masked_path>/port.c:2853
#11 ##### in Vmxnet3VMKDevTQDoTx (port=port@entry=#####, tqIdx=tqIdx@entry=0, callSite=<optimized out>)
    at <masked_path>/vmxnet3_vmkdev.c:5023
#12 ##### in Vmxnet3VMKDev_AsyncTx (port=#####, qidMap=0) at <masked_path>/vmxnet3_vmkdev.c:5607
#13 ##### in NetWorldPerVMCBInt (vmInfo=#####) at <masked_path>/net_world.c:56
#14 NetWorldPerVMCB (data=#####) at <masked_path>/net_world.c:139
#15 ##### in CpuSched_StartWorld (destWorld=<optimized out>, previous=<optimized out>) at <masked_path>/cpusched.c:15328
#16 ##### in ?? () at <masked_path>/debug.c:4125
#17 0x0000000000000000 in ?? ()

Environment

VMware NSX

VMware vDefend Firewall

Cause

This issue is caused by a double-free race condition within the VSIP module (VSIPDVFProcessPacketsInt). When packet processing fails during list iteration in the DFW/IDPS slowpath evaluation, a packet handle is released and freed back to the slab allocator. However, the VSIP layer retains a reference to the freed packet variable after the loop terminates and attempts to execute an attribute clear (FC_PktAttrClear), leading to a write-after-free and memory slab corruption.

Versions Affected: NSX 4.2.1, 4.2.2, 4.2.3, 9.1

Resolution

Workaround: None available.

Disabling Flow Cache is not recommended as a resolution, as the underlying issue stems from packet attribute clearing in the VSIP/DFW slowpath handling rather than flow cache exhaustion.

This issue is resolved in upcoming NSX and targeted maintenance releases.