[PATCH v2 0/1] vhost: tolerate fd in REM_MEM_REG for interop

[PATCH v2 0/1] vhost: tolerate fd in REM_MEM_REG for interop

[pravin.bathija]

From: Pravin M Bathija <pravin.bathija@dell.com>

This is version v2 of the patch and it incorporates the recommendations
made by AI code review.

The VHOST_USER_REM_MEM_REG handler rejects messages carrying a file
descriptor, but the vhost-user specification allows back-ends to
accept one for compatibility with incorrect front-end implementations.

libblkio (v1.5.0) sends an fd with REM_MEM_REG because it shares a
message helper with ADD_MEM_REG.  This causes DPDK to drop the
connection with:

  expect 0 FDs for request VHOST_USER_REM_MEM_REG, received 1

QEMU's libvhost-user reference back-end already tolerates this.

The fix accepts the message and closes any unexpected fd without
using it, conforming to the specification's compatibility clause.

Also added Release notes as suggested by AI code review.

Tested with:
 - QEMU VM bring-up with add/remove memory regions via monitor
 - QEMU post-copy live migration between source and destination
 - SPDK vhost-blk with libblkio fio engine (write + md5 verify)
 - libblkio alloc-mem-region and map-mem-region unit tests
   (ADD/REM/ADD cycles against SPDK vhost-blk)

Version Log:

Version v2 (Current Version): Added release notes entry (review feedback)
Version v1: Initial patch

Pravin M Bathija (1):
  vhost: tolerate file descriptor in REM_MEM_REG msg

 doc/guides/rel_notes/release_26_07.rst | 8 ++++++++
 lib/vhost/vhost_user.c                 | 9 ++++++++-
 2 files changed, 16 insertions(+), 1 deletion(-)

-- 
2.43.0

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

[pravin.bathija]

From: Pravin M Bathija <pravin.bathija@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.

QEMU's libvhost-user reference back-end (vu_rem_mem_reg) already
tolerates zero or one fd in this message.  Align DPDK's behavior
with both the specification's compatibility clause and the reference
implementation by accepting the message and closing any unexpected fd.

Tested with:
 - QEMU VM bring-up with runtime add/remove memory regions via
   QEMU monitor
 - QEMU post-copy live migration between source and destination
 - SPDK vhost-blk with libblkio (fio libblkio engine, write + md5
   verify)
 - libblkio alloc-mem-region and map-mem-region tests exercising
   ADD_MEM_REG / REM_MEM_REG / ADD_MEM_REG cycles against SPDK
   vhost-blk

Fixes: 1d730eea6a42 ("vhost: add memory region handlers")
Cc: stable@dpdk.org

Signed-off-by: Pravin M Bathija <pravin.bathija@dell.com>
---
 doc/guides/rel_notes/release_26_07.rst | 8 ++++++++
 lib/vhost/vhost_user.c                 | 9 ++++++++-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/doc/guides/rel_notes/release_26_07.rst b/doc/guides/rel_notes/release_26_07.rst
index 3d18ba2dd0..86042bd5e3 100644
--- a/doc/guides/rel_notes/release_26_07.rst
+++ b/doc/guides/rel_notes/release_26_07.rst
@@ -85,6 +85,14 @@ New Features
   to support adding and removing memory regions without resetting
   the whole guest memory map.
 
+* **Fixed vhost REM_MEM_REG compatibility with front-ends sending file descriptors.**
+
+  The vhost-user ``REM_MEM_REG`` message handler now tolerates
+  an unexpected file descriptor sent by the front-end,
+  closing it without use as permitted by the vhost-user specification.
+  This fixes interoperability with front-ends such as libblkio
+  that unconditionally attach a file descriptor to the message.
+
 * **Updated Google gve driver.**
 
   Added hardware timestamping support on DQO queues.
diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 020c993b29..82c62f2f64 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -73,7 +73,7 @@ VHOST_MESSAGE_HANDLER(VHOST_USER_RESET_OWNER, vhost_user_reset_owner, false, fal
 VHOST_MESSAGE_HANDLER(VHOST_USER_SET_MEM_TABLE, vhost_user_set_mem_table, true, true) \
 VHOST_MESSAGE_HANDLER(VHOST_USER_GET_MAX_MEM_SLOTS, vhost_user_get_max_mem_slots, false, false) \
 VHOST_MESSAGE_HANDLER(VHOST_USER_ADD_MEM_REG, vhost_user_add_mem_reg, true, true) \
-VHOST_MESSAGE_HANDLER(VHOST_USER_REM_MEM_REG, vhost_user_rem_mem_reg, false, true) \
+VHOST_MESSAGE_HANDLER(VHOST_USER_REM_MEM_REG, vhost_user_rem_mem_reg, true, true) \
 VHOST_MESSAGE_HANDLER(VHOST_USER_SET_LOG_BASE, vhost_user_set_log_base, true, true) \
 VHOST_MESSAGE_HANDLER(VHOST_USER_SET_LOG_FD, vhost_user_set_log_fd, true, true) \
 VHOST_MESSAGE_HANDLER(VHOST_USER_SET_VRING_NUM, vhost_user_set_vring_num, false, true) \
@@ -1811,6 +1811,13 @@ vhost_user_rem_mem_reg(struct virtio_net **pdev,
 	struct virtio_net *dev = *pdev;
 	uint32_t i;
 
+	/*
+	 * The specification says no file descriptor should be passed with
+	 * this message, but some front-ends send one anyway. Tolerate it and
+	 * close it without using it, as the specification requires.
+	 */
+	close_msg_fds(ctx);
+
 	if (dev->mem == NULL || dev->mem->nregions == 0) {
 		VHOST_CONFIG_LOG(dev->ifname, ERR, "no memory regions to remove");
 		return RTE_VHOST_MSG_RESULT_ERR;
-- 
2.43.0

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

[David Marchand]

On Fri, 31 Jul 2026 at 05:14, <pravin.bathija@dell.com> wrote:
>
> From: Pravin M Bathija <pravin.bathija@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...

>
> QEMU's libvhost-user reference back-end (vu_rem_mem_reg) already
> tolerates zero or one fd in this message.  Align DPDK's behavior
> with both the specification's compatibility clause and the reference
> implementation by accepting the message and closing any unexpected fd.
>
> Tested with:
>  - QEMU VM bring-up with runtime add/remove memory regions via
>    QEMU monitor
>  - QEMU post-copy live migration between source and destination
>  - SPDK vhost-blk with libblkio (fio libblkio engine, write + md5
>    verify)
>  - libblkio alloc-mem-region and map-mem-region tests exercising
>    ADD_MEM_REG / REM_MEM_REG / ADD_MEM_REG cycles against SPDK
>    vhost-blk
>
> Fixes: 1d730eea6a42 ("vhost: add memory region handlers")
> Cc: stable@dpdk.org
>
> Signed-off-by: Pravin M Bathija <pravin.bathija@dell.com>
> ---
>  doc/guides/rel_notes/release_26_07.rst | 8 ++++++++
>  lib/vhost/vhost_user.c                 | 9 ++++++++-
>  2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/rel_notes/release_26_07.rst b/doc/guides/rel_notes/release_26_07.rst
> index 3d18ba2dd0..86042bd5e3 100644
> --- a/doc/guides/rel_notes/release_26_07.rst
> +++ b/doc/guides/rel_notes/release_26_07.rst

We are working on 26.*11* ...


> @@ -85,6 +85,14 @@ New Features
>    to support adding and removing memory regions without resetting
>    the whole guest memory map.
>
> +* **Fixed vhost REM_MEM_REG compatibility with front-ends sending file descriptors.**
> +
> +  The vhost-user ``REM_MEM_REG`` message handler now tolerates
> +  an unexpected file descriptor sent by the front-end,
> +  closing it without use as permitted by the vhost-user specification.
> +  This fixes interoperability with front-ends such as libblkio
> +  that unconditionally attach a file descriptor to the message.
> +

... and regardless of the version this was put in, this is not a feature.

We usually don't put Fixes: in RN.
The AI bot nags too much.


-- 
David Marchand

RE: [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@redhat.com>
> Sent: Thursday, July 30, 2026 11:22 PM
> To: Bathija, Pravin <Pravin.Bathija@dell.com>; stephen@networkplumber.org
> Cc: dev@dpdk.org; maxime.coquelin@redhat.com;
> fengchengwen@huawei.com; stable@dpdk.org; thomas@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@dell.com> wrote:
> >
> > From: Pravin M Bathija <pravin.bathija@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."

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

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.

> >
> > QEMU's libvhost-user reference back-end (vu_rem_mem_reg) already
> > tolerates zero or one fd in this message.  Align DPDK's behavior with
> > both the specification's compatibility clause and the reference
> > implementation by accepting the message and closing any unexpected fd.
> >
> > Tested with:
> >  - QEMU VM bring-up with runtime add/remove memory regions via
> >    QEMU monitor
> >  - QEMU post-copy live migration between source and destination
> >  - SPDK vhost-blk with libblkio (fio libblkio engine, write + md5
> >    verify)
> >  - libblkio alloc-mem-region and map-mem-region tests exercising
> >    ADD_MEM_REG / REM_MEM_REG / ADD_MEM_REG cycles against SPDK
> >    vhost-blk
> >
> > Fixes: 1d730eea6a42 ("vhost: add memory region handlers")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Pravin M Bathija <pravin.bathija@dell.com>
> > ---
> >  doc/guides/rel_notes/release_26_07.rst | 8 ++++++++
> >  lib/vhost/vhost_user.c                 | 9 ++++++++-
> >  2 files changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/rel_notes/release_26_07.rst
> > b/doc/guides/rel_notes/release_26_07.rst
> > index 3d18ba2dd0..86042bd5e3 100644
> > --- a/doc/guides/rel_notes/release_26_07.rst
> > +++ b/doc/guides/rel_notes/release_26_07.rst
>
> We are working on 26.*11* ...
>
>
> > @@ -85,6 +85,14 @@ New Features
> >    to support adding and removing memory regions without resetting
> >    the whole guest memory map.
> >
> > +* **Fixed vhost REM_MEM_REG compatibility with front-ends sending
> > +file descriptors.**
> > +
> > +  The vhost-user ``REM_MEM_REG`` message handler now tolerates  an
> > + unexpected file descriptor sent by the front-end,  closing it
> > + without use as permitted by the vhost-user specification.
> > +  This fixes interoperability with front-ends such as libblkio  that
> > + unconditionally attach a file descriptor to the message.
> > +
>
> ... and regardless of the version this was put in, this is not a feature.
>
> We usually don't put Fixes: in RN.
> The AI bot nags too much.
>
>
> --
> David Marchand

Re: [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@dell.com> wrote:
> Internal Use - Confidential

It is not.

> > -----Original Message-----
> > From: David Marchand <david.marchand@redhat.com>
> > Sent: Thursday, July 30, 2026 11:22 PM
> > To: Bathija, Pravin <Pravin.Bathija@dell.com>; stephen@networkplumber.org
> > Cc: dev@dpdk.org; maxime.coquelin@redhat.com;
> > fengchengwen@huawei.com; stable@dpdk.org; thomas@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@dell.com> wrote:
> > >
> > > From: Pravin M Bathija <pravin.bathija@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

RE: [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@redhat.com>
> Sent: Friday, July 31, 2026 12:28 AM
> To: Bathija, Pravin <Pravin.Bathija@dell.com>
> Cc: stephen@networkplumber.org; dev@dpdk.org;
> maxime.coquelin@redhat.com; fengchengwen@huawei.com;
> stable@dpdk.org; thomas@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@dell.com> wrote:
> > Internal Use - Confidential
>
> It is not.
>
> > > -----Original Message-----
> > > From: David Marchand <david.marchand@redhat.com>
> > > Sent: Thursday, July 30, 2026 11:22 PM
> > > To: Bathija, Pravin <Pravin.Bathija@dell.com>;
> > > stephen@networkplumber.org
> > > Cc: dev@dpdk.org; maxime.coquelin@redhat.com;
> > > fengchengwen@huawei.com; stable@dpdk.org; thomas@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@dell.com> wrote:
> > > >
> > > > From: Pravin M Bathija <pravin.bathija@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

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

[Stephen Hemminger]

On Fri, 31 Jul 2026 08:19:07 +0000
"Bathija, Pravin" <Pravin.Bathija@dell.com> wrote:

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

IMHO security safety trumps the specification in this case.
Although it might help to document this somewhere and add a better message.

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

[Bathija, Pravin]

Internal Use - Confidential
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Friday, July 31, 2026 8:28 AM
> To: Bathija, Pravin <Pravin.Bathija@dell.com>
> Cc: David Marchand <david.marchand@redhat.com>; dev@dpdk.org;
> maxime.coquelin@redhat.com; fengchengwen@huawei.com;
> stable@dpdk.org; thomas@monjalon.net
> Subject: Re: [PATCH v2 1/1] vhost: tolerate file descriptor in REM_MEM_REG
> msg
>
>
> [EXTERNAL EMAIL]
>
> On Fri, 31 Jul 2026 08:19:07 +0000
> "Bathija, Pravin" <Pravin.Bathija@dell.com> wrote:
>
> > > > 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.
>
> IMHO security safety trumps the specification in this case.
> Although it might help to document this somewhere and add a better message.

Agreed that security comes first. The patch does close the fd immediately via
close_msg_fds(ctx), so there's no leak risk. Happy to add a log message so it's visible when a
front-end sends an unexpected fd. Something like:

if (ctx->fd_num > 0)
    VHOST_CONFIG_LOG(dev->ifname, WARNING,
        "REM_MEM_REG received with %d unexpected fd(s), closing",
        ctx->fd_num);
close_msg_fds(ctx);

Would that address your concern? I'll include it in v4.