| Message ID | 20250402-kasan_slab-use-after-free_read_in_sctp_outq_select_transport-v1-1-da6f5f00f286@igalia.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | sctp: check transport existence before processing a send primitive | expand |
On Wed, Apr 02, 2025 at 12:25:36PM +0200, Ricardo Cañuelo Navarro 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 causes the access to > the transport data in sctp_outq_select_transport(), when the association > outqueue is flushed, to do a use-after-free read. > > This patch addresses this scenario by checking if the transport still > exists right after the chunks to be sent are set up to use it and before > proceeding to sending them. If the transport was freed since it was > found, the send is aborted. The reason to add the check here is that > once the transport is assigned to the chunks, deleting that transport > is safe, since it will also set chunk->transport to NULL in the affected > chunks. This scenario is correctly handled already, see Fixes below. > > 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@vger.kernel.org > Fixes: df132eff4638 ("sctp: clear the transport of some out_chunk_list chunks in sctp_assoc_rm_peer") > Signed-off-by: Ricardo Cañuelo Navarro <rcn@igalia.com> > --- > net/sctp/socket.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/net/sctp/socket.c b/net/sctp/socket.c > index 36ee34f483d703ffcfe5ca9e6cc554fba24c75ef..9c5ff44fa73cae6a6a04790800cc33dfa08a8da9 100644 > --- a/net/sctp/socket.c > +++ b/net/sctp/socket.c > @@ -1787,17 +1787,24 @@ static int sctp_sendmsg_check_sflags(struct sctp_association *asoc, > return 1; > } > > +static union sctp_addr *sctp_sendmsg_get_daddr(struct sock *sk, > + const struct msghdr *msg, > + struct sctp_cmsgs *cmsgs); > + > static int sctp_sendmsg_to_asoc(struct sctp_association *asoc, > struct msghdr *msg, size_t msg_len, > struct sctp_transport *transport, > struct sctp_sndrcvinfo *sinfo) > { > + struct sctp_transport *aux_transport = NULL; > struct sock *sk = asoc->base.sk; > + struct sctp_endpoint *ep = sctp_sk(sk)->ep; > struct sctp_sock *sp = sctp_sk(sk); > struct net *net = sock_net(sk); > struct sctp_datamsg *datamsg; > bool wait_connect = false; > struct sctp_chunk *chunk; > + union sctp_addr *daddr; > long timeo; > int err; > > @@ -1869,6 +1876,15 @@ static int sctp_sendmsg_to_asoc(struct sctp_association *asoc, > sctp_set_owner_w(chunk); > chunk->transport = transport; > } > + /* Fail if transport was deleted after lookup in sctp_sendmsg() */ > + daddr = sctp_sendmsg_get_daddr(sk, msg, NULL); > + if (daddr) { > + sctp_endpoint_lookup_assoc(ep, daddr, &aux_transport); > + if (!aux_transport || aux_transport != transport) { > + sctp_datamsg_free(datamsg); > + goto err; Hi Ricardo, This is not a full review, and I would suggest waiting for one from others. But this will result in the local variable err being used uninitialised. Flagged by Smatch. > + } > + } > > err = sctp_primitive_SEND(net, asoc, datamsg); > if (err) {
Hi Simon, On Wed, 2025-04-02 at 14:21 +0100, Simon Horman wrote: > Hi Ricardo, > > This is not a full review, and I would suggest waiting for one from > others. > But this will result in the local variable err being used > uninitialised. > > Flagged by Smatch. Nice catch! Thanks, I'll queue a fix for this for v2. Cheers, Ricardo
By the way, I'm thinking of setting err to -EAGAIN here so that userspace can retry the send and sctp_sendmsg() will try again to find a suitable association or create a new one if necessary, but if someone more knowledgeable about the SCTP implementation has a better suggestion about what kind of error to return in this scenario, I'd appreciate it. Regards, Ricardo
On Wed, Apr 2, 2025 at 6:26 AM Ricardo Cañuelo Navarro <rcn@igalia.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 causes the access to > the transport data in sctp_outq_select_transport(), when the association > outqueue is flushed, to do a use-after-free read. > The data send path: sctp_endpoint_lookup_assoc() -> sctp_sendmsg_to_asoc() And the transport removal path: sctp_sf_do_asconf() -> sctp_process_asconf() -> sctp_assoc_rm_peer() are both protected by the same socket lock. Additionally, when a path is removed, sctp_assoc_rm_peer() updates the transport of all existing chunks in the send queues (peer->transmitted and asoc->outqueue.out_chunk_list) to NULL. It will be great if you can reproduce the issue locally and help check how the potential race occurs. > This patch addresses this scenario by checking if the transport still > exists right after the chunks to be sent are set up to use it and before > proceeding to sending them. If the transport was freed since it was > found, the send is aborted. The reason to add the check here is that > once the transport is assigned to the chunks, deleting that transport > is safe, since it will also set chunk->transport to NULL in the affected > chunks. This scenario is correctly handled already, see Fixes below. > > 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@vger.kernel.org > Fixes: df132eff4638 ("sctp: clear the transport of some out_chunk_list chunks in sctp_assoc_rm_peer") > Signed-off-by: Ricardo Cañuelo Navarro <rcn@igalia.com> > --- > net/sctp/socket.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/net/sctp/socket.c b/net/sctp/socket.c > index 36ee34f483d703ffcfe5ca9e6cc554fba24c75ef..9c5ff44fa73cae6a6a04790800cc33dfa08a8da9 100644 > --- a/net/sctp/socket.c > +++ b/net/sctp/socket.c > @@ -1787,17 +1787,24 @@ static int sctp_sendmsg_check_sflags(struct sctp_association *asoc, > return 1; > } > > +static union sctp_addr *sctp_sendmsg_get_daddr(struct sock *sk, > + const struct msghdr *msg, > + struct sctp_cmsgs *cmsgs); > + > static int sctp_sendmsg_to_asoc(struct sctp_association *asoc, > struct msghdr *msg, size_t msg_len, > struct sctp_transport *transport, > struct sctp_sndrcvinfo *sinfo) > { > + struct sctp_transport *aux_transport = NULL; > struct sock *sk = asoc->base.sk; > + struct sctp_endpoint *ep = sctp_sk(sk)->ep; > struct sctp_sock *sp = sctp_sk(sk); > struct net *net = sock_net(sk); > struct sctp_datamsg *datamsg; > bool wait_connect = false; > struct sctp_chunk *chunk; > + union sctp_addr *daddr; > long timeo; > int err; > > @@ -1869,6 +1876,15 @@ static int sctp_sendmsg_to_asoc(struct sctp_association *asoc, > sctp_set_owner_w(chunk); > chunk->transport = transport; > } > + /* Fail if transport was deleted after lookup in sctp_sendmsg() */ > + daddr = sctp_sendmsg_get_daddr(sk, msg, NULL); > + if (daddr) { > + sctp_endpoint_lookup_assoc(ep, daddr, &aux_transport); > + if (!aux_transport || aux_transport != transport) { > + sctp_datamsg_free(datamsg); > + goto err; > + } > + } > We should avoid an extra hashtable lookup on this hot TX path, as it would negatively impact performance. Thanks. > err = sctp_primitive_SEND(net, asoc, datamsg); > if (err) { > > --- > base-commit: 38fec10eb60d687e30c8c6b5420d86e8149f7557 > change-id: 20250402-kasan_slab-use-after-free_read_in_sctp_outq_select_transport-46c9c30bcb7d >
Thanks for reviewing, answers below: On Wed, Apr 02 2025 at 15:40:56, Xin Long <lucien.xin@gmail.com> wrote: > The data send path: > > sctp_endpoint_lookup_assoc() -> > sctp_sendmsg_to_asoc() > > And the transport removal path: > > sctp_sf_do_asconf() -> > sctp_process_asconf() -> > sctp_assoc_rm_peer() > > are both protected by the same socket lock. > > Additionally, when a path is removed, sctp_assoc_rm_peer() updates the > transport of all existing chunks in the send queues (peer->transmitted > and asoc->outqueue.out_chunk_list) to NULL. > > It will be great if you can reproduce the issue locally and help check > how the potential race occurs. That's true but if there isn't enough space in the send buffer, then sctp_sendmsg_to_asoc() will release the lock temporarily. The scenario that the reproducer generates is the following: Thread A Thread B -------------------- -------------------- (1) sctp_sendmsg() lock_sock() sctp_sendmsg_to_asoc() sctp_wait_for_sndbuf() release_sock() sctp_setsockopt(SCTP_SOCKOPT_BINDX_REM) lock_sock() sctp_setsockopt_bindx() sctp_send_asconf_del_ip() ... release_sock() process rcv backlog: sctp_do_sm() sctp_sf_do_asconf() ... sctp_assoc_rm_peer() lock_sock() (2) chunk->transport = transport sctp_primitive_SEND() ... sctp_outq_select_transport() *BUG* switch (new_transport->state) Notes: ------ Both threads operate on the same socket. 1. Here, sctp_endpoint_lookup_assoc() finds and returns an existing association and transport. 2. At this point, `transport` is already deleted. chunk->transport is not set to NULL because sctp_assoc_rm_peer() ran _before_ the transport was assigned to the chunk. > We should avoid an extra hashtable lookup on this hot TX path, as it would > negatively impact performance. Good point. I can't really tell the performance impact of the lookup here, my experience with the SCTP implementation is very limited. Do you have any suggestions or alternatives about how to deal with this? Thanks, Ricardo
On Thu, Apr 3, 2025 at 5:58 AM Ricardo Cañuelo Navarro <rcn@igalia.com> wrote: > > Thanks for reviewing, answers below: > > On Wed, Apr 02 2025 at 15:40:56, Xin Long <lucien.xin@gmail.com> wrote: > > The data send path: > > > > sctp_endpoint_lookup_assoc() -> > > sctp_sendmsg_to_asoc() > > > > And the transport removal path: > > > > sctp_sf_do_asconf() -> > > sctp_process_asconf() -> > > sctp_assoc_rm_peer() > > > > are both protected by the same socket lock. > > > > Additionally, when a path is removed, sctp_assoc_rm_peer() updates the > > transport of all existing chunks in the send queues (peer->transmitted > > and asoc->outqueue.out_chunk_list) to NULL. > > > > It will be great if you can reproduce the issue locally and help check > > how the potential race occurs. > > That's true but if there isn't enough space in the send buffer, then > sctp_sendmsg_to_asoc() will release the lock temporarily. > Oh right, I missed that. Thanks. > The scenario that the reproducer generates is the following: > > Thread A Thread B > -------------------- -------------------- > (1) sctp_sendmsg() > lock_sock() > sctp_sendmsg_to_asoc() > sctp_wait_for_sndbuf() > release_sock() > sctp_setsockopt(SCTP_SOCKOPT_BINDX_REM) > lock_sock() > sctp_setsockopt_bindx() > sctp_send_asconf_del_ip() > ... > release_sock() > process rcv backlog: > sctp_do_sm() > sctp_sf_do_asconf() > ... > sctp_assoc_rm_peer() > lock_sock() > (2) chunk->transport = transport > sctp_primitive_SEND() > ... > sctp_outq_select_transport() > *BUG* switch (new_transport->state) > > > Notes: > ------ > > Both threads operate on the same socket. > > 1. Here, sctp_endpoint_lookup_assoc() finds and returns an existing > association and transport. > > 2. At this point, `transport` is already deleted. chunk->transport is > not set to NULL because sctp_assoc_rm_peer() ran _before_ the transport > was assigned to the chunk. > > > We should avoid an extra hashtable lookup on this hot TX path, as it would > > negatively impact performance. > > Good point. I can't really tell the performance impact of the lookup > here, my experience with the SCTP implementation is very limited. Do you > have any suggestions or alternatives about how to deal with this? > I think the correct approach is to follow how sctp_assoc_rm_peer() handles this. You can use asoc->peer.last_sent_to (which isn't really used elsewhere) to temporarily store the transport before releasing the socket lock and sleeping in sctp_sendmsg_to_asoc(). After waking up and reacquiring the lock, restore the transport back to asoc->peer.last_sent_to. Additionally, during an ASCONF update, ensure asoc->peer.last_sent_to is set to a valid transport if it matches the transport being removed. For example: in sctp_wait_for_sndbuf(): asoc->peer.last_sent_to = *tp; release_sock(sk); current_timeo = schedule_timeout(current_timeo); lock_sock(sk); *tp = asoc->peer.last_sent_to; asoc->peer.last_sent_to = NULL; in sctp_assoc_rm_peer(): if (asoc->peer.last_sent_to == peer) asoc->peer.last_sent_to = transport;
On Thu, Apr 3, 2025 at 10:42 AM Xin Long <lucien.xin@gmail.com> wrote: > > On Thu, Apr 3, 2025 at 5:58 AM Ricardo Cañuelo Navarro <rcn@igalia.com> wrote: > > > > Thanks for reviewing, answers below: > > > > On Wed, Apr 02 2025 at 15:40:56, Xin Long <lucien.xin@gmail.com> wrote: > > > The data send path: > > > > > > sctp_endpoint_lookup_assoc() -> > > > sctp_sendmsg_to_asoc() > > > > > > And the transport removal path: > > > > > > sctp_sf_do_asconf() -> > > > sctp_process_asconf() -> > > > sctp_assoc_rm_peer() > > > > > > are both protected by the same socket lock. > > > > > > Additionally, when a path is removed, sctp_assoc_rm_peer() updates the > > > transport of all existing chunks in the send queues (peer->transmitted > > > and asoc->outqueue.out_chunk_list) to NULL. > > > > > > It will be great if you can reproduce the issue locally and help check > > > how the potential race occurs. > > > > That's true but if there isn't enough space in the send buffer, then > > sctp_sendmsg_to_asoc() will release the lock temporarily. > > > Oh right, I missed that. Thanks. > > > The scenario that the reproducer generates is the following: > > > > Thread A Thread B > > -------------------- -------------------- > > (1) sctp_sendmsg() > > lock_sock() > > sctp_sendmsg_to_asoc() > > sctp_wait_for_sndbuf() > > release_sock() > > sctp_setsockopt(SCTP_SOCKOPT_BINDX_REM) > > lock_sock() > > sctp_setsockopt_bindx() > > sctp_send_asconf_del_ip() > > ... > > release_sock() > > process rcv backlog: > > sctp_do_sm() > > sctp_sf_do_asconf() > > ... > > sctp_assoc_rm_peer() > > lock_sock() > > (2) chunk->transport = transport > > sctp_primitive_SEND() > > ... > > sctp_outq_select_transport() > > *BUG* switch (new_transport->state) > > > > > > Notes: > > ------ > > > > Both threads operate on the same socket. > > > > 1. Here, sctp_endpoint_lookup_assoc() finds and returns an existing > > association and transport. > > > > 2. At this point, `transport` is already deleted. chunk->transport is > > not set to NULL because sctp_assoc_rm_peer() ran _before_ the transport > > was assigned to the chunk. > > > > > We should avoid an extra hashtable lookup on this hot TX path, as it would > > > negatively impact performance. > > > > Good point. I can't really tell the performance impact of the lookup > > here, my experience with the SCTP implementation is very limited. Do you > > have any suggestions or alternatives about how to deal with this? > > > I think the correct approach is to follow how sctp_assoc_rm_peer() > handles this. > > You can use asoc->peer.last_sent_to (which isn't really used elsewhere) > to temporarily store the transport before releasing the socket lock and > sleeping in sctp_sendmsg_to_asoc(). After waking up and reacquiring the > lock, restore the transport back to asoc->peer.last_sent_to. > > Additionally, during an ASCONF update, ensure asoc->peer.last_sent_to > is set to a valid transport if it matches the transport being removed. > > For example: > > in sctp_wait_for_sndbuf(): > > asoc->peer.last_sent_to = *tp; > release_sock(sk); > current_timeo = schedule_timeout(current_timeo); > lock_sock(sk); > *tp = asoc->peer.last_sent_to; > asoc->peer.last_sent_to = NULL; > > in sctp_assoc_rm_peer(): > > if (asoc->peer.last_sent_to == peer) > asoc->peer.last_sent_to = transport; This change introduces a side effect: when multiple threads send data on the same asoc using different daddrs, they may interfere with each other while waiting for buffer space, as each thread updates asoc->peer.last_sent_to. You may consider holding a refcnt to the transport (similar to how the asoc refcnt is held) in sctp_wait_for_sndbuf(), as shown below: @@ -9225,7 +9225,9 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p, pr_debug("%s: asoc:%p, timeo:%ld, msg_len:%zu\n", __func__, asoc, *timeo_p, msg_len); - /* Increment the association's refcnt. */ + /* Increment the transport and association's refcnt. */ + if (t) + sctp_transport_hold(t); sctp_association_hold(asoc); /* Wait on the association specific sndbuf space. */ @@ -9234,7 +9236,7 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p, TASK_INTERRUPTIBLE); if (asoc->base.dead) goto do_dead; - if (!*timeo_p) + if (!*timeo_p || (t && t->dead)) goto do_nonblock; if (sk->sk_err || asoc->state >= SCTP_STATE_SHUTDOWN_PENDING) goto do_error; @@ -9259,7 +9261,9 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p, out: finish_wait(&asoc->wait, &wait); - /* Release the association's refcnt. */ + /* Release the transport and association's refcnt. */ + if (t) + sctp_transport_put(t); sctp_association_put(asoc); You will need to reintroduce the dead bit in struct sctp_transport and set it in sctp_transport_free(). Note this field was previously removed in: commit 47faa1e4c50ec26e6e75dcd1ce53f064bd45f729 Author: Xin Long <lucien.xin@gmail.com> Date: Fri Jan 22 01:49:09 2016 +0800 sctp: remove the dead field of sctp_transport Thanks.
On Fri, Apr 4, 2025 at 6:05 AM Ricardo Cañuelo Navarro <rcn@igalia.com> wrote: > > Thanks for the suggestion! > > On Thu, Apr 03 2025 at 14:44:18, Xin Long <lucien.xin@gmail.com> wrote: > > > @@ -9234,7 +9236,7 @@ static int sctp_wait_for_sndbuf(struct > > sctp_association *asoc, long *timeo_p, > > TASK_INTERRUPTIBLE); > > if (asoc->base.dead) > > goto do_dead; > > - if (!*timeo_p) > > + if (!*timeo_p || (t && t->dead)) > > goto do_nonblock; > > if (sk->sk_err || asoc->state >= SCTP_STATE_SHUTDOWN_PENDING) > > goto do_error; > > I suppose checking t->dead should be done after locking the socket > again, where sctp_assoc_rm_peer() may have had a chance to run, rather > than here? > It shouldn't matter, as long as it's protected by the socket lock. The logic would be similar to checking asoc->base.dead. > Something like this: > > @@ -9225,7 +9227,9 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p, > pr_debug("%s: asoc:%p, timeo:%ld, msg_len:%zu\n", __func__, asoc, > *timeo_p, msg_len); > > - /* Increment the association's refcnt. */ > + /* Increment the transport and association's refcnt. */ > + if (transport) > + sctp_transport_hold(transport); > sctp_association_hold(asoc); > > /* Wait on the association specific sndbuf space. */ > @@ -9252,6 +9256,8 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p, > lock_sock(sk); > if (sk != asoc->base.sk) > goto do_error; > + if (transport && transport->dead) > + goto do_nonblock; > > *timeo_p = current_timeo; > } > @@ -9259,7 +9265,9 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p, > out: > finish_wait(&asoc->wait, &wait); > > - /* Release the association's refcnt. */ > + /* Release the transport and association's refcnt. */ > + if (transport) > + sctp_transport_put(transport); > sctp_association_put(asoc); > > return err; > > > So by the time the sending thread re-claims the socket lock it can tell > whether someone else removed the transport by checking transport->dead > (set in sctp_transport_free()) and there's a guarantee that the > transport hasn't been freed yet because we hold a reference to it. > > If the whole receive path through sctp_assoc_rm_peer() is protected by > the same socket lock, as you said, this should be safe. The tests I ran > seem to work fine. If you're ok with it I'll send another patch to > supersede this one. > LGTM. > > > You will need to reintroduce the dead bit in struct sctp_transport and > > set it in sctp_transport_free(). Note this field was previously removed in: > > > > commit 47faa1e4c50ec26e6e75dcd1ce53f064bd45f729 > > Author: Xin Long <lucien.xin@gmail.com> > > Date: Fri Jan 22 01:49:09 2016 +0800 > > > > sctp: remove the dead field of sctp_transport > > I understand that none of the transport->dead checks from that commit > are necessary anymore, since they were replaced by refcnt checks, and > that we'll only bring the bit back for this particular check we're doing > now, correct? Correct, only the 'dead' bit and set it in sctp_transport_free(). Thanks.
diff --git a/net/sctp/socket.c b/net/sctp/socket.c index 36ee34f483d703ffcfe5ca9e6cc554fba24c75ef..9c5ff44fa73cae6a6a04790800cc33dfa08a8da9 100644 --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -1787,17 +1787,24 @@ static int sctp_sendmsg_check_sflags(struct sctp_association *asoc, return 1; } +static union sctp_addr *sctp_sendmsg_get_daddr(struct sock *sk, + const struct msghdr *msg, + struct sctp_cmsgs *cmsgs); + static int sctp_sendmsg_to_asoc(struct sctp_association *asoc, struct msghdr *msg, size_t msg_len, struct sctp_transport *transport, struct sctp_sndrcvinfo *sinfo) { + struct sctp_transport *aux_transport = NULL; struct sock *sk = asoc->base.sk; + struct sctp_endpoint *ep = sctp_sk(sk)->ep; struct sctp_sock *sp = sctp_sk(sk); struct net *net = sock_net(sk); struct sctp_datamsg *datamsg; bool wait_connect = false; struct sctp_chunk *chunk; + union sctp_addr *daddr; long timeo; int err; @@ -1869,6 +1876,15 @@ static int sctp_sendmsg_to_asoc(struct sctp_association *asoc, sctp_set_owner_w(chunk); chunk->transport = transport; } + /* Fail if transport was deleted after lookup in sctp_sendmsg() */ + daddr = sctp_sendmsg_get_daddr(sk, msg, NULL); + if (daddr) { + sctp_endpoint_lookup_assoc(ep, daddr, &aux_transport); + if (!aux_transport || aux_transport != transport) { + sctp_datamsg_free(datamsg); + goto err; + } + } err = sctp_primitive_SEND(net, asoc, datamsg); if (err) {
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 causes the access to the transport data in sctp_outq_select_transport(), when the association outqueue is flushed, to do a use-after-free read. This patch addresses this scenario by checking if the transport still exists right after the chunks to be sent are set up to use it and before proceeding to sending them. If the transport was freed since it was found, the send is aborted. The reason to add the check here is that once the transport is assigned to the chunks, deleting that transport is safe, since it will also set chunk->transport to NULL in the affected chunks. This scenario is correctly handled already, see Fixes below. 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@vger.kernel.org Fixes: df132eff4638 ("sctp: clear the transport of some out_chunk_list chunks in sctp_assoc_rm_peer") Signed-off-by: Ricardo Cañuelo Navarro <rcn@igalia.com> --- net/sctp/socket.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) --- base-commit: 38fec10eb60d687e30c8c6b5420d86e8149f7557 change-id: 20250402-kasan_slab-use-after-free_read_in_sctp_outq_select_transport-46c9c30bcb7d