The minimal size of an ethernet packet is 64 bytes, no matter VLAN header is present there or not. The server is allowed to send a 64 bytes long packet that contains a VLAN, which you should accept and process correctly.
Note:This behaviour is correctly handled by a catalyst 4500x not by Nexus 9k.
How is a Packet Processed by a Switch
Step 1. Receive a VALID 64 bytes Ethernet frame.
Step 2. Remove the Frame Check Sequence (FCS), so the packet becomes 60 bytes long.
Step 3. Remove the VLAN tag, so the packet becomes 56 bytes long.
Step 4. Add padding to make the packet 60 bytes long.
Step 5. It adds the FCS, making the packet 64 bytes long.
Padding should not get modified when a packet goes through cut-through switch.
Padding Modified with Tagged VLANs when Traffic traverses N9K
Instead of padding with zeroes, the packet is padded with garbage characters, in most of the cases it has no impact because checksums are not modified and so nobody uses these datas. However, if customers have a special usage and need to recompute the checksums, these garbage data leads to corruption of checksums in the end (other appliances, like NAT/load-balancers might see the issue too)
Device is a N9K 93120TX (was initially detected on a 9372TX though), version is latest NXOS 7.0(3)I2(2a)
Use Linux hosts with directly connected hardware to the N9K (no virtualization of any kind) here (1000base-T links)