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

[Bathija, Pravin]

Internal Use - Confidential
> -----Original Message-----
> From: David Marchand <david.marchand at redhat.com>
> Sent: Friday, July 31, 2026 12:28 AM
> To: Bathija, Pravin <Pravin.Bathija at dell.com>
> Cc: stephen at networkplumber.org; 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 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 :-)
>
Understood 😊. but the clause is in the spec nonetheless, and other implementations follow it.

>
> > 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.

I couldn't agree with you more.  The libblkio fix is ready and will stop sending the fd.
In an ideal world we'd fix libblkio and move on,  but there are already several released versions
of libblkio in the wild that exhibit this behavior.  Users pairing those with a current DPDK will hit
a broken connection with no obvious workaround.

>
>
> > 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.

The patch does not leave the fd behind — close_msg_fds(ctx) closes it immediately. More
importantly, the fd is already received by the process once recvmsg() delivers it. The current
code rejects the message and drops the connection, but the fd has already been transferred
into the process's fd table at that point. Without closing it explicitly, rejecting actually
causes the leak those CVEs warn about. This patch prevents that.

>
>
> For now, drop the wrong RN update.
>

Thank you. Done in V3

>
> --
> David Marchand