[Bug 270964] iflib/ice(4): invalid sized packet sent via netmap triggers MDD

From: <bugzilla-noreply_at_freebsd.org>
Date: Thu, 20 Apr 2023 19:21:56 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270964

            Bug ID: 270964
           Summary: iflib/ice(4): invalid sized packet sent via netmap
                    triggers MDD
           Product: Base System
           Version: CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: brian90013@gmail.com

Hello,

We recently saw a machine with Intel E810 cards stop transmitting and start
printing "Malicious Driver Detection Tx Descriptor check event 'Packet too
small or too big'" to the console. Some investigation showed a user application
was incorrectly building packets over 9724 bytes and passing them via netmap to
the ice driver.

We quickly avoided the MDD event by fixing the user application. However, I was
surprised there appears to be no length checking when using netmap with iflib
drivers.

Looking at iflib_netmap_txsync(), it assembles the set of fragments composing a
packet and passes them to ctx->isc_txd_encap() aka ice_ift_txd_encap(). That
function has an int return value and seems like an excellent place to compare
the total packet length (in pi->ipi_len) against ICE_MAX_FRAME_SIZE. (In fact
the ixl driver does this with MPASS().)

The issue is iflib_netmap_txsync() ignores the return code and always
increments the nic_i pointer. I have made several attempts to modify this
function to handle failures from isc_txd_encap but none have passed all my
tests.

I wonder if there is a reasonable way to modify iflib_netmap_txsync() to drop
fragments if isc_txd_encap returns an error code? I realize this code is in the
fast path and should be kept to a minimum. However, this change would let the
ice driver (and other iflib users) inspect packet sizes, avoid this class of
MDD events, and keep the interface up and running.

-- 
You are receiving this mail because:
You are the assignee for the bug.