memif: sealed region issues

https://bugs.dpdk.org/show_bug.cgi?id=2019

            Bug ID: 2019
           Summary: memif: sealed region issues
           Product: DPDK
           Version: 26.11
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: ethdev
          Assignee: [email protected]
          Reporter: [email protected]

Target Milestone: ---
Group: security

This is related to bug 2013, and was found by AI review. Fixing it to be fully secure would break some uses.

Sealing: warn, do not reject
----------------------------

A server cannot require F_SEAL_SHRINK today. libmemif seals region 0, but VPP's hugepage-backed and zero-copy buffer regions use MFD_HUGETLB or hugetlbfs and are not sealed, so requiring a seal would disconnect conforming clients.

A narrower rule does not work either. The obvious refinement is to reject when the fd supports sealing but is not sealed, and warn only when the fd type has no seals at all. That cannot be implemented
cleanly: F_GET_SEALS returns F_SEAL_SEAL for a memfd created without MFD_ALLOW_SEALING, so a successful F_GET_SEALS does not mean the client could have sealed and chose not to. Under that rule DPDK would reject peers that had no way to comply, which is the unilateral hardening this work is trying to avoid.

So the proposed fix checks the size with fstat and only logs when the fd is unsealed. Two review points on the logging:

- the log fires for legitimate VPP hugepage clients, which is the common deployment, so at NOTICE it is noise in exactly the normal case and trains operators to ignore it. DEBUG, or once per device, is more defensible;
- it is emitted per region per connection, so a peer that reconnects in a loop can flood the log. That is a small denial of service introduced by the fix itself.

The real fix for the residual exposure is a protocol requirement that clients seal shrinkable regions, negotiated in the hello so that both sides know whether it applies. That cannot be decided by DPDK alone; it is a wire-contract item for DPDK, VPP and libmemif together.

Until then, this bug reduces the exposure to a client that lies about the size at connect time. It does not close the class, and neither the commit message nor the documentation should claim that it does.

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