[PATCH v2 1/1] vhost: tolerate file descriptor in REM_MEM_REG msg

[David Marchand]

On Fri, 31 Jul 2026 at 09:08, Bathija, Pravin <Pravin.Bathija at dell.com> wrote:
> Internal Use - Confidential

It is not.

> > -----Original Message-----
> > From: David Marchand <david.marchand at redhat.com>
> > Sent: Thursday, July 30, 2026 11:22 PM
> > To: Bathija, Pravin <Pravin.Bathija at dell.com>; stephen at networkplumber.org
> > Cc: dev at dpdk.org; maxime.coquelin at redhat.com;
> > fengchengwen at huawei.com; stable at dpdk.org; thomas at monjalon.net
> > Subject: Re: [PATCH v2 1/1] vhost: tolerate file descriptor in REM_MEM_REG
> > msg
> >
> >
> > [EXTERNAL EMAIL]
> >
> > On Fri, 31 Jul 2026 at 05:14, <pravin.bathija at dell.com> wrote:
> > >
> > > From: Pravin M Bathija <pravin.bathija at dell.com>
> > >
> > > The vhost-user specification (vhost-user.rst) states that no file
> > > descriptors SHOULD be passed with VHOST_USER_REM_MEM_REG.
> > However, it
> > > also says: "For compatibility with existing incorrect implementations,
> > > the back-end MAY accept messages with one file descriptor.  If a file
> > > descriptor is passed, the back-end MUST close it without using it
> > > otherwise."
> > >
> > > Some front-ends, notably libblkio, reuse the same message-building
> > > helper for both ADD_MEM_REG and REM_MEM_REG and unconditionally
> > attach
> > > the mapping fd.  The previous implementation rejected any REM_MEM_REG
> > > carrying a file descriptor with the error:
> > >
> > >         expect 0 FDs for request VHOST_USER_REM_MEM_REG, received 1
> > >
> > > This broke teardown and memory region hot-swap with these front-ends.
> > >
> > > To reproduce, run any libblkio (v1.5.0) application using the
> > > virtio-blk-vhost-user driver against a DPDK vhost back-end.  The
> > > connection is dropped during cleanup or whenever a memory region is
> > > unmapped and remapped.
> >
> > Is libblkio fixed now?
> >
> > I am not a fan of such compatibility fix, having to accept one buggy client...
> >
>
> Yes, the libblkio fix is ready and will be submitted upstream within a day or so.
> It stops sending the fd with REM_MEM_REG.
>
> That said, this DPDK fix stands on its own regardless of libblkio. The vhost-user
> specification explicitly anticipates this situation and requires back-ends to handle it:
>
> "For compatibility with existing incorrect implementations, the back-end MAY accept messages
> with one file descriptor. If a file descriptor is passed, the back-end MUST close it without
> using it otherwise."

Well, yes, I understand the specification was updated or written for a
buggy client :-)


> While the immediate motivation was libblkio, the spec's compatibility clause was written for
> exactly this situation — any front-end could make the same mistake. QEMU's libvhost-user
> reference implementation already tolerates it (see vu_rem_mem_reg).

Which does not change that I dislike such compat.


> The fix is 2 lines with no downside: accept the message, close the fd. Rejecting it drops the
> connection entirely, which is a disproportionate response to a harmless extra fd.

Leaving behind a "harmless extra fd" causes exhaustion of a process FD.
At least, CVE-2019-14818 and CVE-2020-10726 come to mind.

So strictly speaking, rejecting is really not disproportionate.


For now, drop the wrong RN update.


-- 
David Marchand