Internal Use - Confidential
> -----Original Message-----
> From: David Marchand <[email protected]>
> Sent: Friday, July 31, 2026 12:28 AM
> To: Bathija, Pravin <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]
> 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 <[email protected]> wrote:
> > Internal Use - Confidential
>
> It is not.
>
> > > -----Original Message-----
> > > From: David Marchand <[email protected]>
> > > Sent: Thursday, July 30, 2026 11:22 PM
> > > To: Bathija, Pravin <[email protected]>;
> > > [email protected]
> > > Cc: [email protected]; [email protected];
> > > [email protected]; [email protected]; [email protected]
> > > 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, <[email protected]> wrote:
> > > >
> > > > From: Pravin M Bathija <[email protected]>
> > > >
> > > > 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
