No subject

[Tim Whisonant]

On Thu, Mar 06, 2025 at 11:39:01AM +0900, Koichiro Den wrote:
> On Wed, Mar 05, 2025 at 02:03:29PM GMT, Tim Whisonant wrote:
> > [Impact]
> > 
> > vsock: Keep the binding until socket destruction
> > 
> > Preserve sockets bindings; this includes both resulting from an explicit
> > bind() and those implicitly bound through autobind during connect().
> > 
> > Prevents socket unbinding during a transport reassignment, which fixes a
> > use-after-free:
> > 
> >     1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)
> >     2. transport->release() calls vsock_remove_bound() without checking if
> >        sk was bound and moved to bound list (refcnt=1)
> >     3. vsock_bind() assumes sk is in unbound list and before
> >        __vsock_insert_bound(vsock_bound_sockets()) calls
> >        __vsock_remove_bound() which does:
> >            list_del_init(&vsk->bound_table); // nop
> >            sock_put(&vsk->sk);               // refcnt=0
> > 
> > vsock: Orphan socket after transport release
> > 
> > During socket release, sock_orphan() is called without considering that it
> > sets sk->sk_wq to NULL. Later, if SO_LINGER is enabled, this leads to a
> > null pointer dereferenced in virtio_transport_wait_close().
> > 
> > Orphan the socket only after transport release.
> > 
> > Partially reverts the 'Fixes:' commit.
> > 
> > [Backport]
> > 
> > Backported from upstream.
> > 
> > [Fix]
> > 
> > Oracular: cherry picked from upstream
> > Noble:    applied Jammy patch
> > Jammy:    backported from upstream
> > Focal:    not affected
> > Bionic:   not affected
> > Xenial:   not affected
> > Trusty:   not affected
> > 
> > [Test Plan]
> > 
> > Compile and boot tested.
> > 
> > [Where problems could occur]
> > 
> > The change affects the ordering of vsock orphan versus release
> > to correct a NULL pointer dereference. Problems could appear in
> > the socket release path.
> > 
> > Michal Luczaj (2):
> >   vsock: Keep the binding until socket destruction
> >   vsock: Orphan socket after transport release
> > 
> >  net/vmw_vsock/af_vsock.c | 12 +++++++++++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> > 
> 
> I'm not sure if you've noticed, but just in case you haven't: the follow-up
> fix is for CVE-2025-21755. As far as I know, there's no strict rule
> requiring us to label either in this situation; thanks to this submission,
> CVE-2025-21755 will never affect any stable master kernels. Therefore, I
> believe tagging both commits with CVE-2025-21756 is not a problem. Other
> than that, LGTM.
> 
> Acked-by: Koichiro Den <koichiro.den at canonical.com>

Thanks for your note. By "tagging both commits", do you mean like below?

(backported from commit ...)
[tswhison: ...]
CVE-2025-21755
CVE-2025-21756
Signed-off-by: Tim Whisonant <tim.whisonant at canonical.com>