linux-kernel - Re: [syzbot] [net?] general protection fault in add_wait

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: <4732bd9f-e202-4895-9ba2-576b571c387a@rbox.co>
Date: Wed, 5 Feb 2025 00:58:12 +0100
From: Michal Luczaj <mhal@...x.co>
To: Stefano Garzarella <sgarzare@...hat.com>
Cc: syzbot <syzbot+9d55b199192a4be7d02c@...kaller.appspotmail.com>,
 davem@...emloft.net, edumazet@...gle.com, eperezma@...hat.com,
 horms@...nel.org, jasowang@...hat.com, kuba@...nel.org, kvm@...r.kernel.org,
 linux-kernel@...r.kernel.org, mst@...hat.com, netdev@...r.kernel.org,
 pabeni@...hat.com, stefanha@...hat.com, syzkaller-bugs@...glegroups.com,
 virtualization@...ts.linux.dev, xuanzhuo@...ux.alibaba.com
Subject: Re: [syzbot] [net?] general protection fault in add_wait_queue

On 2/4/25 11:04, Stefano Garzarella wrote:
> On Tue, 4 Feb 2025 at 10:59, Stefano Garzarella <sgarzare@...hat.com> wrote:
>> On Tue, Feb 04, 2025 at 01:38:50AM +0100, Michal Luczaj wrote:
>>> ...
>>> I'm not sure this is the most elegant code (sock_orphan(sk) sets SOCK_DEAD
>>> on a socket that is already SOCK_DEAD), but here it goes:
>>> https://lore.kernel.org/netdev/20250204-vsock-linger-nullderef-v1-0-6eb1760fa93e@rbox.co/
>>
>> What about the fix proposed here:
>> https://lore.kernel.org/lkml/20250203124959.114591-1-aha310510@gmail.com/
> 
> mmm, nope, that one will completely bypass the lingering, right?

Right. Besides that, it's a transport-specific approach, so all the other
transports would need their .release() tweaked.

>>> One more note: man socket(7) says lingering also happens on shutdown().
>>> Should vsock follow that?
>>
>> Good point, I think so.
>> IMHO we should handle both of them in af_vsock.c if it's possible, but
>> maybe we need a bit of refactoring.
>>
>> Anyway, net-next material, right?

Yeah, I guess.

Michal