Userland used in writeback path was Re: [PATCH] nbd: restrict sockets to TCP and UDP

Userland used in writeback path was Re: [PATCH] nbd: restrict sockets to TCP and UDP

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

On Tue 2025-11-18 18:16:23, Richard W.M. Jones wrote:
> On Tue, Nov 18, 2025 at 06:56:33PM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > Recently, syzbot started to abuse NBD with all kinds of sockets.
> > > 
> > > Commit cf1b2326b734 ("nbd: verify socket is supported during setup")
> > > made sure the socket supported a shutdown() method.
> > > 
> > > Explicitely accept TCP and UNIX stream sockets.
> > 
> > Note that running nbd server and client on same machine is not safe in
> > read-write mode. It may deadlock under low memory conditions.
> > 
> > Thus I'm not sure if we should accept UNIX sockets.
> 
> Both nbd-client and nbdkit have modes where they can mlock themselves
> into RAM.

kernel needs memory. It issues write-back to get some.
nbd-client does syscall. Maybe writing to storage?
That syscall does kmalloc().
That kmalloc now needs something like PF_MEMALLOC flag.

mlock() is not enough.

Best regards,
							Pavel
-- 
I don't work for Nazis and criminals, and neither should you.
Boycott Putin, Trump, Netanyahu and Musk!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Userland used in writeback path was Re: [PATCH] nbd: restrict sockets to TCP and UDP

[Richard W.M. Jones]

On Wed, Nov 19, 2025 at 10:10:37AM +0100, Pavel Machek wrote:
> On Tue 2025-11-18 18:16:23, Richard W.M. Jones wrote:
> > On Tue, Nov 18, 2025 at 06:56:33PM +0100, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > Recently, syzbot started to abuse NBD with all kinds of sockets.
> > > > 
> > > > Commit cf1b2326b734 ("nbd: verify socket is supported during setup")
> > > > made sure the socket supported a shutdown() method.
> > > > 
> > > > Explicitely accept TCP and UNIX stream sockets.
> > > 
> > > Note that running nbd server and client on same machine is not safe in
> > > read-write mode. It may deadlock under low memory conditions.
> > > 
> > > Thus I'm not sure if we should accept UNIX sockets.
> > 
> > Both nbd-client and nbdkit have modes where they can mlock themselves
> > into RAM.
> 
> kernel needs memory. It issues write-back to get some.
> nbd-client does syscall. Maybe writing to storage?
> That syscall does kmalloc().
> That kmalloc now needs something like PF_MEMALLOC flag.
> 
> mlock() is not enough.

There are loads of use cases for NBD over a Unix domain socket that
have nothing to do with storage.  nbdkit supports all sorts of purely
virtual and remote devices.

Practically, we use this feature successfully all the time without any
issues, so we'd appreciate it not being broken over some very
theoretical concern that you haven't even been able to demonstrate in
a test case.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v