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

On Fri, 31 Jul 2026 at 09:08, Bathija, Pravin <[email protected]> wro=
te:
> 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]=
rg
> > 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 cl=
ient...
> >
>
> Yes, the libblkio fix is ready and will be submitted upstream within a da=
y or so.
> It stops sending the fd with REM_MEM_REG.
>
> That said, this DPDK fix stands on its own regardless of libblkio. The vh=
ost-user
> specification explicitly anticipates this situation and requires back-end=
s 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 MU=
ST 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 cla=
use was written for
> exactly this situation =E2=80=94 any front-end could make the same mistak=
e. 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. Re=
jecting it drops the
> connection entirely, which is a disproportionate response to a harmless e=
xtra 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.


--=20
David Marchand