[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240422130031.GA77895@fedora>
Date: Mon, 22 Apr 2024 09:00:31 -0400
From: Stefan Hajnoczi <stefanha@...hat.com>
To: Jeongjun Park <aha310510@...il.com>
Cc: mst@...hat.com, jasowang@...hat.com, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, sgarzare@...hat.com,
syzbot+6c21aeb59d0e82eb2782@...kaller.appspotmail.com,
syzkaller-bugs@...glegroups.com, virtualization@...ts.linux.dev,
Arseny Krasnov <arseny.krasnov@...persky.com>
Subject: Re: [PATCH virt] virt: fix uninit-value in vhost_vsock_dev_open
On Sun, Apr 21, 2024 at 12:06:06PM +0900, Jeongjun Park wrote:
> static bool vhost_transport_seqpacket_allow(u32 remote_cid)
> {
> ....
> vsock = vhost_vsock_get(remote_cid);
>
> if (vsock)
> seqpacket_allow = vsock->seqpacket_allow;
> ....
> }
>
> I think this is due to reading a previously created uninitialized
> vsock->seqpacket_allow inside vhost_transport_seqpacket_allow(),
> which is executed by the function pointer present in the if statement.
CCing Arseny, author of commit ced7b713711f ("vhost/vsock: support
SEQPACKET for transport").
Looks like a genuine bug in the commit. vhost_vsock_set_features() sets
seqpacket_allow to true when the feature is negotiated. The assumption
is that the field defaults to false.
The rest of the vhost_vsock.ko code is written to initialize the
vhost_vsock fields, so you could argue seqpacket_allow should just be
explicitly initialized to false.
However, eliminating this class of errors by zeroing seems reasonable in
this code path. vhost_vsock_dev_open() is not performance-critical.
Acked-by: Stefan Hajnoczi <stefanha@...hat.com>
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists