[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e1161184-e2fa-49eb-8093-0b754dc362c1@kernel.dk>
Date: Tue, 9 Sep 2025 09:09:31 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "Richard W.M. Jones" <rjones@...hat.com>,
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
Subject: Re: [PATCH] nbd: restrict sockets to TCP and UDP
On 9/9/25 8:47 AM, 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
>>>
>>> So you will have to fix this.
>>
>> Rather than play whack-a-mole with this, would it make sense to mark as
>> socket as "writeback/reclaim" safe and base the nbd decision on that rather
>> than attempt to maintain some allow/deny list of sockets?
>
> Even if a socket type was writeback/reclaim safe, probably NBD would
> not support arbitrary socket type, like netlink, af_packet, or
> af_netrom.
>
> An allow list seems safer to me, with commits with a clear owner.
>
> If future syzbot reports are triggered, the bisection will point to
> these commits.
That's fine too, either approach will result in fixups, at the end of
the day. And followup related fixes to solve issues with socket types
that we do deem useful, like the vsock one you already found.
--
Jens Axboe
Powered by blists - more mailing lists