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

[Xin Long]

On Mon, Aug 10, 2026 at 7:42 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
>
> On Mon, 10 Aug 2026 09:09:15 -0400 Xin Long wrote:
> > On Sun, Aug 9, 2026 at 12:38 AM Yuxiang Yang
> > <yangyx22@xxxxxxxxxxxxxxxxxxxxx> 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 <lucien.xin@xxxxxxxxx>
>
> 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/20260809043806.2768302-1-yangyx22@xxxxxxxxxxxxxxxxxxxxx

These are two pre-existing issues:

- The 1st one needs to clear more state for ADDIP in
  sctp_asconf_queue_teardown(), such as src_out_of_asoc_ok and
  asconf_addr_del_pending.

- The 2nd one needs to check whether the expiry matches the ASCONF it was
  armed for. We may also need to add a new member to the association, such
  as last_addip_serial.

We’ll need some time to reproduce and confirm these issues. Since neither
causes a crash (unlike this issue),and the current patch does not make
either of them worse, I think it would be better to address them separately
in later patches.

Thanks.