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.
