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