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

[Bathija, Pravin]

Internal Use - Confidential
> -----Original Message-----
> From: Stephen Hemminger <stephen at networkplumber.org>
> Sent: Friday, July 31, 2026 8:28 AM
> To: Bathija, Pravin <Pravin.Bathija at dell.com>
> Cc: David Marchand <david.marchand at redhat.com>; 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 08:19:07 +0000
> "Bathija, Pravin" <Pravin.Bathija at 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.