linux-kernel - Re: [PATCH] nbd: restrict sockets to TCP and UDP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <p43lkbkmsgnztlfbnrebsnnlkdvz4lt53vmnenoarejg6lhivz@cbia5lxat73k>
Date: Wed, 10 Sep 2025 17:55:45 +0200
From: Stefano Garzarella <sgarzare@...hat.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "Richard W.M. Jones" <rjones@...hat.com>, Jens Axboe <axboe@...nel.dk>, 
	Josef Bacik <josef@...icpanda.com>, linux-kernel <linux-kernel@...r.kernel.org>, 
	netdev@...r.kernel.org, Eric Dumazet <eric.dumazet@...il.com>, 
	syzbot+e1cd6bd8493060bd701d@...kaller.appspotmail.com, Mike Christie <mchristi@...hat.com>, 
	Yu Kuai <yukuai1@...weicloud.com>, linux-block@...r.kernel.org, nbd@...er.debian.org, 
	Stefan Hajnoczi <stefanha@...hat.com>
Subject: Re: [PATCH] nbd: restrict sockets to TCP and UDP

On Tue, Sep 09, 2025 at 08:33:27AM -0700, Eric Dumazet wrote:
>On Tue, Sep 9, 2025 at 8:19 AM Richard W.M. Jones <rjones@...hat.com> wrote:
>>
>> On Tue, Sep 09, 2025 at 07:47:09AM -0700, Eric Dumazet wrote:
>> > On Tue, Sep 9, 2025 at 7:37 AM Jens Axboe <axboe@...nel.dk> wrote:
>> > >
>> > > On 9/9/25 8:35 AM, Eric Dumazet wrote:
>> > > > On Tue, Sep 9, 2025 at 7:04 AM Eric Dumazet <edumazet@...gle.com> wrote:
>> > > >>
>> > > >> On Tue, Sep 9, 2025 at 6:32 AM Richard W.M. Jones <rjones@...hat.com> wrote:
>> > > >>>
>> > > >>> On Tue, Sep 09, 2025 at 01:22:43PM +0000, Eric Dumazet wrote:
>> > > >>>> 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.
>> > > >>>
>> > > >>> I'm not clear what the actual problem is, but I will say that libnbd &
>> > > >>> nbdkit (which are another NBD client & server, interoperable with the
>> > > >>> kernel) we support and use NBD over vsock[1].  And we could support
>> > > >>> NBD over pretty much any stream socket (Infiniband?) [2].
>> > > >>>
>> > > >>> [1] https://libguestfs.org/nbd_aio_connect_vsock.3.html
>> > > >>>     https://libguestfs.org/nbdkit-service.1.html#AF_VSOCK
>> > > >>> [2] https://libguestfs.org/nbd_connect_socket.3.html
>> > > >>>
>> > > >>> TCP and Unix domain sockets are by far the most widely used, but I
>> > > >>> don't think it's fair to exclude other socket types.
>> > > >>
>> > > >> If we have known and supported socket types, please send a patch to add them.
>> > > >>
>> > > >> I asked the question last week and got nothing about vsock or other types.
>> > > >>
>> > > >> https://lore.kernel.org/netdev/CANn89iLNFHBMTF2Pb6hHERYpuih9eQZb6A12+ndzBcQs_kZoBA@mail.gmail.com/
>> > > >>
>> > > >> For sure, we do not want datagram sockets, RAW, netlink, and many others.
>> > > >
>> > > > BTW vsock will probably fire lockdep warnings, I see GFP_KERNEL
>> > > > being used in net/vmw_vsock/virtio_transport.c
>>
>> CC-ing Stefan & Stefano.  Myself, I'm only using libnbd
>> (ie. userspace) over vsock, not the kernel client.

Thanks Rich for cceing me!

>>
>> > > > So you will have to fix this.

How we should fix that?

IIUC GFP_KERNEL in virtio_transport.c is used only by workqueue's 
functions, but we have GFP_ATOMIC in the fast path that can be called 
when the user is sending a packet.

This is basically the driver for the virtio-vsock device that can 
allocates extra buffers to be exposed to the device.
In this case the allocation can happen in virtqueue_add_sgs() for virtio 
indirect buffer, that IIRC virtio-vsock is not using currently (but we 
don't know in the future).

In any case, we use GFP_KERNEL also in virtio_transport_common.c to 
allocate the sk_buff, so that should be the same issue.

Thanks,
Stefano