linux-kernel - Re: [PATCH] sctp: detect and prevent references to a freed transport in sendmsg

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: <CADvbK_fRgqPTJGK7w_ujuiSVqwt_XPUaisd2Qp_t--yf6NuS8A@mail.gmail.com>
Date: Mon, 7 Apr 2025 11:05:22 -0400
From: Xin Long <lucien.xin@...il.com>
To: Ricardo Cañuelo Navarro <rcn@...lia.com>
Cc: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Simon Horman <horms@...nel.org>, revest@...gle.com, kernel-dev@...lia.com, 
	linux-sctp@...r.kernel.org, netdev@...r.kernel.org, 
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] sctp: detect and prevent references to a freed transport
 in sendmsg

On Fri, Apr 4, 2025 at 10:54 AM Ricardo Cañuelo Navarro <rcn@...lia.com> wrote:
>
> sctp_sendmsg() re-uses associations and transports when possible by
> doing a lookup based on the socket endpoint and the message destination
> address, and then sctp_sendmsg_to_asoc() sets the selected transport in
> all the message chunks to be sent.
>
> There's a possible race condition if another thread triggers the removal
> of that selected transport, for instance, by explicitly unbinding an
> address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have
> been set up and before the message is sent. This can happen if the send
> buffer is full, during the period when the sender thread temporarily
> releases the socket lock in sctp_wait_for_sndbuf().
>
> This causes the access to the transport data in
> sctp_outq_select_transport(), when the association outqueue is flushed,
> to result in a use-after-free read.
>
> This change avoids this scenario by having sctp_transport_free() signal
> the freeing of the transport, tagging it as "dead". In order to do this,
> the patch restores the "dead" bit in struct sctp_transport, which was
> removed in
> commit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").
>
> Then, in the scenario where the sender thread has released the socket
> lock in sctp_wait_for_sndbuf(), the bit is checked again after
> re-acquiring the socket lock to detect the deletion. This is done while
> holding a reference to the transport to prevent it from being freed in
> the process.
>
> If the transport was deleted while the socket lock was relinquished,
> sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the
> send.
>
> The bug was found by a private syzbot instance (see the error report [1]
> and the C reproducer that triggers it [2]).
>
> Link: https://people.igalia.com/rcn/kernel_logs/20250402__KASAN_slab-use-after-free_Read_in_sctp_outq_select_transport.txt [1]
> Link: https://people.igalia.com/rcn/kernel_logs/20250402__KASAN_slab-use-after-free_Read_in_sctp_outq_select_transport__repro.c [2]
> Cc: stable@...r.kernel.org
> Fixes: df132eff4638 ("sctp: clear the transport of some out_chunk_list chunks in sctp_assoc_rm_peer")
> Suggested-by: Xin Long <lucien.xin@...il.com>
> Signed-off-by: Ricardo Cañuelo Navarro <rcn@...lia.com>

Acked-by: Xin Long <lucien.xin@...il.com>

Thanks