ACK/Cmnt: [SRU][J/N/O][PATCH 0/2] CVE-2025-21756

[Koichiro Den]

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>