Re: [PATCH net v3] sctp: fix use-after-free of cached ASCONF chunk

On Mon, 10 Aug 2026 09:09:15 -0400 Xin Long wrote:
> On Sun, Aug 9, 2026 at 12:38 AM Yuxiang Yang
> <[email protected]> wrote:
> >
> > addip_last_asconf caches the outstanding outbound ASCONF chunk. The normal
> > ASCONF-ACK completion path releases the chunk and clears the pointer.
> >
> > However, sctp_asconf_queue_teardown() releases the cached chunk without
> > clearing addip_last_asconf. During peer restart handling,
> > sctp_sf_do_dupcook_a() queues SCTP_CMD_PURGE_ASCONF_QUEUE, which invokes
> > sctp_asconf_queue_teardown() while the association remains alive and leaves
> > the pointer dangling.
> >
> > A delayed authenticated ASCONF-ACK can then reach sctp_sf_do_asconf_ack(),
> > which accesses the stale chunk and passes it to sctp_process_asconf_ack(),
> > causing a use-after-free and a second release.
> >
> > Clearing the pointer exposes a race with T4 expiry. Peer restart handling
> > queues the timer stop before the purge, but SCTP_CMD_TIMER_STOP uses
> > timer_delete(), which does not wait for a callback already running on
> > another CPU. Such a callback can reach sctp_sf_t4_timer_expire() after
> > the purge and dereference NULL.
> >
> > Clear addip_last_asconf after releasing the cached chunk, and make
> > sctp_sf_t4_timer_expire() consume a stale T4 expiry if no outstanding
> > ASCONF remains.
> 
> Acked-by: Xin Long <[email protected]>

Hi! I think *shiko has a different suggestion which it thinks covers
more cases. Does it make sense?

https://netdev-ai.bots.linux.dev/sashiko/#/patchset/[email protected]