[PATCH v2] sctp: fix refcount bug in sctp_wfree

[PATCH v2] sctp: fix refcount bug in sctp_wfree

[Qiujun Huang]

Do accounting for skb's real sk.
In some case skb->sk != asoc->base.sk:

migrate routing        sctp_check_transmitted routing
------------                    ---------------
lock_sock_nested();
                               mv the transmitted skb to
                               the it's local tlist

sctp_for_each_tx_datachunk(
sctp_clear_owner_w);
sctp_assoc_migrate();
sctp_for_each_tx_datachunk(
sctp_set_owner_w);

                               put the skb back to the
                               assoc lists
----------------------------------------------------

The skbs which held bysctp_check_transmitted were not changed
to newsk. They were not dealt with by sctp_for_each_tx_datachunk
(sctp_clear_owner_w/sctp_set_owner_w).

It looks only trouble here so handling it in sctp_wfree is enough.

Reported-and-tested-by: syzbot+cea71eec5d6de256d54d@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
---
 net/sctp/socket.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 1b56fc440606..5f5c28b30e25 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -9080,7 +9080,7 @@ static void sctp_wfree(struct sk_buff *skb)
 {
 	struct sctp_chunk *chunk = skb_shinfo(skb)->destructor_arg;
 	struct sctp_association *asoc = chunk->asoc;
-	struct sock *sk = asoc->base.sk;
+	struct sock *sk = skb->sk;
 
 	sk_mem_uncharge(sk, skb->truesize);
 	sk->sk_wmem_queued -= skb->truesize + sizeof(struct sctp_chunk);
@@ -9109,7 +9109,7 @@ static void sctp_wfree(struct sk_buff *skb)
 	}
 
 	sock_wfree(skb);
-	sctp_wake_up_waiters(sk, asoc);
+	sctp_wake_up_waiters(asoc->base.sk, asoc);
 
 	sctp_association_put(asoc);
 }
-- 
2.17.1

Re: [PATCH v2] sctp: fix refcount bug in sctp_wfree

[Marcelo Ricardo Leitner]

Hi,

On Tue, Mar 17, 2020 at 11:55:36PM +0800, Qiujun Huang wrote:
> Do accounting for skb's real sk.
> In some case skb->sk != asoc->base.sk:
> 
> migrate routing        sctp_check_transmitted routing
> ------------                    ---------------
                                 sctp_close();
				   lock_sock(sk2);
				 sctp_primitive_ABORT();
                                 sctp_do_sm();
                                 sctp_cmd_interpreter();
                                 sctp_cmd_process_sack();
                                 sctp_outq_sack();
				 sctp_check_transmitted();

  lock_sock(sk1);
  sctp_getsockopt_peeloff();
  sctp_do_peeloff();
  sctp_sock_migrate();
> lock_sock_nested(sk2);
>                                mv the transmitted skb to
>                                the it's local tlist


How can sctp_do_sm() be called in the 2nd column so that it bypasses
the locks in the left column, allowing this mv to happen?

> 
> sctp_for_each_tx_datachunk(
> sctp_clear_owner_w);
> sctp_assoc_migrate();
> sctp_for_each_tx_datachunk(
> sctp_set_owner_w);
> 
>                                put the skb back to the
>                                assoc lists
> ----------------------------------------------------
> 
> The skbs which held bysctp_check_transmitted were not changed
> to newsk. They were not dealt with by sctp_for_each_tx_datachunk
> (sctp_clear_owner_w/sctp_set_owner_w).

It would make sense but I'm missing one step earlier, I'm not seeing
how the move to local list is allowed/possible in there. It really
shouldn't be possible.

> 
> It looks only trouble here so handling it in sctp_wfree is enough.
> 
> Reported-and-tested-by: syzbot+cea71eec5d6de256d54d@syzkaller.appspotmail.com
> Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
> ---
>  net/sctp/socket.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 1b56fc440606..5f5c28b30e25 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -9080,7 +9080,7 @@ static void sctp_wfree(struct sk_buff *skb)
>  {
>  	struct sctp_chunk *chunk = skb_shinfo(skb)->destructor_arg;
>  	struct sctp_association *asoc = chunk->asoc;
> -	struct sock *sk = asoc->base.sk;
> +	struct sock *sk = skb->sk;
>  
>  	sk_mem_uncharge(sk, skb->truesize);
>  	sk->sk_wmem_queued -= skb->truesize + sizeof(struct sctp_chunk);
> @@ -9109,7 +9109,7 @@ static void sctp_wfree(struct sk_buff *skb)
>  	}
>  
>  	sock_wfree(skb);
> -	sctp_wake_up_waiters(sk, asoc);
> +	sctp_wake_up_waiters(asoc->base.sk, asoc);
>  
>  	sctp_association_put(asoc);
>  }
> -- 
> 2.17.1
> 

Re: [PATCH v2] sctp: fix refcount bug in sctp_wfree

[Qiujun Huang]

On Wed, Mar 18, 2020 at 1:30 AM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> Hi,
>
> On Tue, Mar 17, 2020 at 11:55:36PM +0800, Qiujun Huang wrote:
> > Do accounting for skb's real sk.
> > In some case skb->sk != asoc->base.sk:
> >
> > migrate routing        sctp_check_transmitted routing
> > ------------                    ---------------
>                                  sctp_close();
>                                    lock_sock(sk2);
>                                  sctp_primitive_ABORT();
>                                  sctp_do_sm();
>                                  sctp_cmd_interpreter();
>                                  sctp_cmd_process_sack();
>                                  sctp_outq_sack();
>                                  sctp_check_transmitted();
>
>   lock_sock(sk1);
>   sctp_getsockopt_peeloff();
>   sctp_do_peeloff();
>   sctp_sock_migrate();
> > lock_sock_nested(sk2);
> >                                mv the transmitted skb to
> >                                the it's local tlist
>
>
> How can sctp_do_sm() be called in the 2nd column so that it bypasses
> the locks in the left column, allowing this mv to happen?
>
> >
> > sctp_for_each_tx_datachunk(
> > sctp_clear_owner_w);
> > sctp_assoc_migrate();
> > sctp_for_each_tx_datachunk(
> > sctp_set_owner_w);
> >
> >                                put the skb back to the
> >                                assoc lists
> > ----------------------------------------------------
> >
> > The skbs which held bysctp_check_transmitted were not changed
> > to newsk. They were not dealt with by sctp_for_each_tx_datachunk
> > (sctp_clear_owner_w/sctp_set_owner_w).
>
> It would make sense but I'm missing one step earlier, I'm not seeing
> how the move to local list is allowed/possible in there. It really
> shouldn't be possible.

I totally agree that.
My mistake. So I added some log in my test showing the case:
The backtrace:
sctp_close
sctp_primitive_ABORT
sctp_do_sm
sctp_association_free
__sctp_outq_teardown
     /* Throw away unacknowledged chunks. */
    list_for_each_entry(transport, &q->asoc->peer.transport_addr_list,
    transports) {
    printk("[%d]deal with transmitted %#llx from transport %#llx  %s,
%d\n", raw_smp_processor_id(),
   &transport->transmitted, transport, __func__, __LINE__);
   while ((lchunk = sctp_list_dequeue(&transport->transmitted)) != NULL) {

The trouble skb is from another peer sk in the same asoc, but
accounted to the base.sk.

Re: [PATCH v2] sctp: fix refcount bug in sctp_wfree

[Marcelo Ricardo Leitner]

On Wed, Mar 18, 2020 at 10:45:51AM +0800, Qiujun Huang wrote:
> On Wed, Mar 18, 2020 at 1:30 AM Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> >
> > Hi,
> >
> > On Tue, Mar 17, 2020 at 11:55:36PM +0800, Qiujun Huang wrote:
> > > Do accounting for skb's real sk.
> > > In some case skb->sk != asoc->base.sk:
> > >
> > > migrate routing        sctp_check_transmitted routing
> > > ------------                    ---------------
> >                                  sctp_close();
> >                                    lock_sock(sk2);
> >                                  sctp_primitive_ABORT();
> >                                  sctp_do_sm();
> >                                  sctp_cmd_interpreter();
> >                                  sctp_cmd_process_sack();
> >                                  sctp_outq_sack();
> >                                  sctp_check_transmitted();
> >
> >   lock_sock(sk1);
> >   sctp_getsockopt_peeloff();
> >   sctp_do_peeloff();
> >   sctp_sock_migrate();
> > > lock_sock_nested(sk2);
> > >                                mv the transmitted skb to
> > >                                the it's local tlist
> >
> >
> > How can sctp_do_sm() be called in the 2nd column so that it bypasses
> > the locks in the left column, allowing this mv to happen?
> >
> > >
> > > sctp_for_each_tx_datachunk(
> > > sctp_clear_owner_w);
> > > sctp_assoc_migrate();
> > > sctp_for_each_tx_datachunk(
> > > sctp_set_owner_w);
> > >
> > >                                put the skb back to the
> > >                                assoc lists
> > > ----------------------------------------------------
> > >
> > > The skbs which held bysctp_check_transmitted were not changed
> > > to newsk. They were not dealt with by sctp_for_each_tx_datachunk
> > > (sctp_clear_owner_w/sctp_set_owner_w).
> >
> > It would make sense but I'm missing one step earlier, I'm not seeing
> > how the move to local list is allowed/possible in there. It really
> > shouldn't be possible.
> 
> I totally agree that.
> My mistake. So I added some log in my test showing the case:
> The backtrace:
> sctp_close
> sctp_primitive_ABORT
> sctp_do_sm
> sctp_association_free
> __sctp_outq_teardown
>      /* Throw away unacknowledged chunks. */
>     list_for_each_entry(transport, &q->asoc->peer.transport_addr_list,
>     transports) {
>     printk("[%d]deal with transmitted %#llx from transport %#llx  %s,
> %d\n", raw_smp_processor_id(),
>    &transport->transmitted, transport, __func__, __LINE__);
>    while ((lchunk = sctp_list_dequeue(&transport->transmitted)) != NULL) {
> 
> The trouble skb is from another peer sk in the same asoc, but
> accounted to the base.sk.

Hmm, not sure how you got that out of that debug msg, but okay.
Even if so, how would this trouble skb be accounted on the wrong sk by
then?

Asking because the fix that we want may be a better locking, to
prevent this situation from happening, than compensating for it in
sctp_wfree(). But for that we need to understand how this happened.

  Marcelo

Re: [PATCH v2] sctp: fix refcount bug in sctp_wfree

[Qiujun Huang]

On Wed, Mar 18, 2020 at 11:55 AM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> On Wed, Mar 18, 2020 at 10:45:51AM +0800, Qiujun Huang wrote:
>
> Hmm, not sure how you got that out of that debug msg, but okay.
> Even if so, how would this trouble skb be accounted on the wrong sk by
> then?
>
> Asking because the fix that we want may be a better locking, to
> prevent this situation from happening, than compensating for it in
> sctp_wfree(). But for that we need to understand how this happened.
>

Yes, I should find the root cause. Here is the log

[   86.507432][ T8813] [1]skb 0xffff88809fdfc800 0xffff88809621e7c0:
truesize 768, sk alloc 769 sctp_set_owner_w 137
[   86.532042][ T8813] [1]skb 0xffff888099ebbe80 0xffff88809621e7c0:
truesize 131328, sk alloc 132353 sctp_set_owner_w 137
[   86.543426][ T8813] [1]skb 0xffff88809ef55cc0 0xffff88809621e7c0:
truesize 131328, sk alloc 263937 sctp_set_owner_w 137
[   86.563229][ T8813] [1]skb 0xffff88809ef557c0 0xffff88809621e7c0:
truesize 131328, sk alloc 395521 sctp_set_owner_w 137
[   86.589332][ T8813] [1]skb 0xffff88809ef55a40 0xffff88809621e7c0:
truesize 33024, sk alloc 428801 sctp_set_owner_w 137
[   86.602211][ T8813] [1]deal with transmitted 0xffff8880910b0a80
from transport 0xffff8880910b0800  __sctp_outq_teardown, 216
[   86.616336][ T8813] [1]put back to queue 0xffff888091dc8770
sctp_check_transmitted, 1683
[   86.625610][ T8813] [1]get packet 0xffff888099ebbe80 from queue
0xffff888096b2c280  sctp_check_transmitted, 1437
[   86.637105][ T8813] [1]put skb 0xffff888099ebbe80 back.
sctp_check_transmitted, 1533
[   86.646284][ T8813] [1]put back to queue 0xffff888096b2c280
sctp_check_transmitted, 1683          ----
[   86.687575][ T8813] [1]before sk 0xffff88809621e7c0
sctp_sock_migrate, 9592                               ----I think
something wrong opens here. 0xffff888099ebbe80 not changed to newsk
[   86.696296][ T8813] [1]skb 0xffff88809ef55cc0 0xffff88809621e7c0:
truesize 131328, sk alloc 429057 sctp_wfree 9101 real sk
0xffff88809621e7c0
[   86.721891][ T8813] [1]transmitted done queue 0xffff888091dc83d0
sctp_for_each_tx_datachunk, 166
[   86.757260][ T8813] [1]retransmit done queue 0xffff888091dc8770
sctp_for_each_tx_datachunk, 171
[   86.771065][ T8813] [1]sacked done queue 0xffff888091dc8760
sctp_for_each_tx_datachunk, 176
[   86.797487][ T8813] [1]abandoned done queue 0xffff888091dc8780
sctp_for_each_tx_datachunk, 181
[   86.814856][ T8813] [0]skb 0xffff88809ef557c0 0xffff88809621e7c0:
truesize 131328, sk alloc 297473 sctp_wfree 9101 real sk
0xffff88809621e7c0
[   86.831799][ T8813] [0]skb 0xffff88809ef55a40 0xffff88809621e7c0:
truesize 33024, sk alloc 165889 sctp_wfree 9101 real sk
0xffff88809621e7c0
[   86.845473][ T8813] [0]out_chunk_list done queue 0xffff888091dc8730
sctp_for_each_tx_datachunk, 186
[   86.866011][ T8813] [0]skb 0xffff88809ef55cc0 0xffff8880a3bb2800:
truesize 131328, sk alloc 131329 sctp_set_owner_w 137
[   86.884811][ T8813] [0]transmitted done queue 0xffff888091dc83d0
sctp_for_each_tx_datachunk, 166
[   86.896150][ T8813] [0]retransmit done queue 0xffff888091dc8770
sctp_for_each_tx_datachunk, 171
[   86.907233][ T8813] [0]sacked done queue 0xffff888091dc8760
sctp_for_each_tx_datachunk, 176
[   86.916825][ T8813] [0]abandoned done queue 0xffff888091dc8780
sctp_for_each_tx_datachunk, 181
[   86.927458][ T8813] [0]skb 0xffff88809ef557c0 0xffff8880a3bb2800:
truesize 131328, sk alloc 262913 sctp_set_owner_w 137
[   86.957446][ T8813] [0]skb 0xffff88809ef55a40 0xffff8880a3bb2800:
truesize 33024, sk alloc 296193 sctp_set_owner_w 137
[   86.971810][ T8813] [0]out_chunk_list done queue 0xffff888091dc8730
sctp_for_each_tx_datachunk, 186
[   86.992386][ T8813] [0]after sk 0xffff8880a3bb2800 sctp_sock_migrate, 9597
[   87.091320][ T8811] [1]deal with transmitted 0xffff8880a6f52280
from transport 0xffff8880a6f52000  __sctp_outq_teardown, 216
[   87.110552][ T8811] [1]skb 0xffff88809fdfc800 0xffff88809621e7c0:
truesize 768, sk alloc 132609 sctp_wfree 9101 real sk
0xffff88809621e7c0
[   87.180238][ T8811] [0]deal with transmitted 0xffff888096b2c280
from transport 0xffff888096b2c000  __sctp_outq_teardown, 216
[   87.264062][ T8811] [0]skb 0xffff888099ebbe80 0xffff8880a3bb2800:
truesize 131328, sk alloc 296449 sctp_wfree 9101 real sk
0xffff88809621e7c0       --->the trouble skb
[   87.289730][ T8811] [1]skb 0xffff88809ef55cc0 0xffff8880a3bb2800:
truesize 131328, sk alloc 296193 sctp_wfree 9101 real sk
0xffff8880a3bb2800
[   87.314206][ T8811] [1]skb 0xffff88809ef557c0 0xffff8880a3bb2800:
truesize 131328, sk alloc 164609 sctp_wfree 9101 real sk
0xffff8880a3bb2800
[   87.329602][ T8811] [1]skb 0xffff88809ef55a40 0xffff8880a3bb2800:
truesize 33024, sk alloc 33025 sctp_wfree 9101 real sk
0xffff8880a3bb2800

>   Marcelo

Re: [PATCH v2] sctp: fix refcount bug in sctp_wfree

[Qiujun Huang]

[-- Attachment #1: Type: text/plain, Size: 12 bytes --]

add log.txt

[-- Attachment #2: log.txt --]
[-- Type: text/plain, Size: 8248 bytes --]

[   86.507432][ T8813] [1]skb 0xffff88809fdfc800 0xffff88809621e7c0: truesize 768, sk alloc 769 sctp_set_owner_w 137
[   86.532042][ T8813] [1]skb 0xffff888099ebbe80 0xffff88809621e7c0: truesize 131328, sk alloc 132353 sctp_set_owner_w 137
[   86.543426][ T8813] [1]skb 0xffff88809ef55cc0 0xffff88809621e7c0: truesize 131328, sk alloc 263937 sctp_set_owner_w 137
[   86.563229][ T8813] [1]skb 0xffff88809ef557c0 0xffff88809621e7c0: truesize 131328, sk alloc 395521 sctp_set_owner_w 137
[   86.589332][ T8813] [1]skb 0xffff88809ef55a40 0xffff88809621e7c0: truesize 33024, sk alloc 428801 sctp_set_owner_w 137
[   86.602211][ T8813] [1]deal with transmitted 0xffff8880910b0a80 from transport 0xffff8880910b0800  __sctp_outq_teardown, 216
[   86.616336][ T8813] [1]put back to queue 0xffff888091dc8770 sctp_check_transmitted, 1683
[   86.625610][ T8813] [1]get packet 0xffff888099ebbe80 from queue 0xffff888096b2c280  sctp_check_transmitted, 1437
[   86.637105][ T8813] [1]put skb 0xffff888099ebbe80 back. sctp_check_transmitted, 1533
[   86.646284][ T8813] [1]put back to queue 0xffff888096b2c280 sctp_check_transmitted, 1683
[   86.687575][ T8813] [1]before sk 0xffff88809621e7c0 sctp_sock_migrate, 9592
[   86.696296][ T8813] [1]skb 0xffff88809ef55cc0 0xffff88809621e7c0: truesize 131328, sk alloc 429057 sctp_wfree 9101 real sk 0xffff88809621e7c0
[   86.721891][ T8813] [1]transmitted done queue 0xffff888091dc83d0 sctp_for_each_tx_datachunk, 166
[   86.757260][ T8813] [1]retransmit done queue 0xffff888091dc8770 sctp_for_each_tx_datachunk, 171
[   86.771065][ T8813] [1]sacked done queue 0xffff888091dc8760 sctp_for_each_tx_datachunk, 176
[   86.797487][ T8813] [1]abandoned done queue 0xffff888091dc8780 sctp_for_each_tx_datachunk, 181
[   86.814856][ T8813] [0]skb 0xffff88809ef557c0 0xffff88809621e7c0: truesize 131328, sk alloc 297473 sctp_wfree 9101 real sk 0xffff88809621e7c0
[   86.831799][ T8813] [0]skb 0xffff88809ef55a40 0xffff88809621e7c0: truesize 33024, sk alloc 165889 sctp_wfree 9101 real sk 0xffff88809621e7c0
[   86.845473][ T8813] [0]out_chunk_list done queue 0xffff888091dc8730 sctp_for_each_tx_datachunk, 186
[   86.866011][ T8813] [0]skb 0xffff88809ef55cc0 0xffff8880a3bb2800: truesize 131328, sk alloc 131329 sctp_set_owner_w 137
[   86.884811][ T8813] [0]transmitted done queue 0xffff888091dc83d0 sctp_for_each_tx_datachunk, 166
[   86.896150][ T8813] [0]retransmit done queue 0xffff888091dc8770 sctp_for_each_tx_datachunk, 171
[   86.907233][ T8813] [0]sacked done queue 0xffff888091dc8760 sctp_for_each_tx_datachunk, 176
[   86.916825][ T8813] [0]abandoned done queue 0xffff888091dc8780 sctp_for_each_tx_datachunk, 181
[   86.927458][ T8813] [0]skb 0xffff88809ef557c0 0xffff8880a3bb2800: truesize 131328, sk alloc 262913 sctp_set_owner_w 137
[   86.957446][ T8813] [0]skb 0xffff88809ef55a40 0xffff8880a3bb2800: truesize 33024, sk alloc 296193 sctp_set_owner_w 137
[   86.971810][ T8813] [0]out_chunk_list done queue 0xffff888091dc8730 sctp_for_each_tx_datachunk, 186
[   86.992386][ T8813] [0]after sk 0xffff8880a3bb2800 sctp_sock_migrate, 9597
[   87.091320][ T8811] [1]deal with transmitted 0xffff8880a6f52280 from transport 0xffff8880a6f52000  __sctp_outq_teardown, 216
[   87.110552][ T8811] [1]skb 0xffff88809fdfc800 0xffff88809621e7c0: truesize 768, sk alloc 132609 sctp_wfree 9101 real sk 0xffff88809621e7c0
[   87.180238][ T8811] [0]deal with transmitted 0xffff888096b2c280 from transport 0xffff888096b2c000  __sctp_outq_teardown, 216
[   87.264062][ T8811] [0]skb 0xffff888099ebbe80 0xffff8880a3bb2800: truesize 131328, sk alloc 296449 sctp_wfree 9101 real sk 0xffff88809621e7c0
[   87.289730][ T8811] [1]skb 0xffff88809ef55cc0 0xffff8880a3bb2800: truesize 131328, sk alloc 296193 sctp_wfree 9101 real sk 0xffff8880a3bb2800
[   87.314206][ T8811] [1]skb 0xffff88809ef557c0 0xffff8880a3bb2800: truesize 131328, sk alloc 164609 sctp_wfree 9101 real sk 0xffff8880a3bb2800
[   87.329602][ T8811] [1]skb 0xffff88809ef55a40 0xffff8880a3bb2800: truesize 33024, sk alloc 33025 sctp_wfree 9101 real sk 0xffff8880a3bb2800
[   87.356930][ T8811] ------------[ cut here ]------------
[   87.397711][ T8811] refcount_t: underflow; use-after-free.
[   87.428445][ T8811] WARNING: CPU: 1 PID: 8811 at lib/refcount.c:28 refcount_warn_saturate+0x15b/0x1a0
[   87.438015][ T8811] Kernel panic - not syncing: panic_on_warn set ...
[   87.444630][ T8811] CPU: 1 PID: 8811 Comm: syz-executor.2 Not tainted 5.6.0-rc5-syzkaller #0
[   87.444635][ T8811] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
[   87.444639][ T8811] Call Trace:
[   87.444656][ T8811]  dump_stack+0x1e9/0x30e
[   87.444671][ T8811]  panic+0x264/0x7a0
[   87.444684][ T8811]  ? __warn+0x102/0x210
[   87.469197][ T8811]  ? refcount_warn_saturate+0x15b/0x1a0
[   87.469209][ T8811]  __warn+0x209/0x210
[   87.469223][ T8811]  ? refcount_warn_saturate+0x15b/0x1a0
[   87.469230][ T8811]  report_bug+0x1ac/0x2d0
[   87.469249][ T8811]  do_error_trap+0xca/0x1c0
[   87.476852][ T8811]  do_invalid_op+0x32/0x40
[   87.507399][ T8811]  ? refcount_warn_saturate+0x15b/0x1a0
[   87.507411][ T8811]  invalid_op+0x23/0x30
[   87.507420][ T8811] RIP: 0010:refcount_warn_saturate+0x15b/0x1a0
[   87.507431][ T8811] Code: c7 d4 00 d1 88 31 c0 e8 33 1f b3 fd 0f 0b eb 85 e8 2a 4a e0 fd c6 05 4e 70 b1 05 01 48 c7 c7 00 01 d1 88 31 c0 e8 15 1f b3 fd <0f> 0b e9 64 ff ff ff e8 09 4a e0 fd c6 05 2e 70 b1 05 01 48 c7 c7
[   87.516277][ T8811] RSP: 0018:ffffc90002f778b0 EFLAGS: 00010246
[   87.533885][ T8811] RAX: dcf57551ce0b1d00 RBX: 0000000000000003 RCX: ffff8880a7eee0c0
[   87.533891][ T8811] RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
[   87.533897][ T8811] RBP: 0000000000000003 R08: ffffffff815e16d6 R09: ffffed1015d26618
[   87.533903][ T8811] R10: ffffed1015d26618 R11: 0000000000000000 R12: dffffc0000000000
[   87.533909][ T8811] R13: ffff888091dc8000 R14: 1ffff11014dd2840 R15: ffff8880a6e94200
[   87.533936][ T8811]  ? vprintk_emit+0x2e6/0x3b0
[   87.550833][ T8811]  sctp_wfree+0x449/0x7e0
[   87.550859][ T8811]  skb_release_head_state+0xfb/0x210
[   87.550877][ T8811]  __kfree_skb+0x22/0x1c0
[   87.576635][ T8811]  sctp_chunk_put+0x17b/0x200
[   87.576654][ T8811]  __sctp_outq_teardown+0x5a9/0x980
[   87.576672][ T8811]  sctp_association_free+0x21e/0x7c0
[   87.576682][ T8811]  ? sctp_do_sm+0x2e2a/0x5560
[   87.576702][ T8811]  sctp_do_sm+0x3c01/0x5560
[   87.595604][ T8811]  ? rcu_read_lock_sched_held+0x106/0x170
[   87.595631][ T8811]  ? _sctp_make_chunk+0x10c/0x3e0
[   87.609465][ T8811]  ? rcu_read_lock_sched_held+0x106/0x170
[   87.609476][ T8811]  ? trace_kmem_cache_alloc+0xcb/0x120
[   87.609489][ T8811]  ? _sctp_make_chunk+0x10c/0x3e0
[   87.609499][ T8811]  ? sctp_auth_send_cid+0x60/0x250
[   87.609534][ T8811]  sctp_primitive_ABORT+0x93/0xc0
[   87.625458][ T8811]  sctp_close+0x2aa/0x7d0
[   87.625482][ T8811]  ? ip_mc_drop_socket+0x267/0x280
[   87.625501][ T8811]  inet_release+0x135/0x180
[   87.641685][ T8811]  sock_close+0xd8/0x260
[   87.641699][ T8811]  ? sock_mmap+0x90/0x90
[   87.641708][ T8811]  __fput+0x2d8/0x730
[   87.641733][ T8811]  task_work_run+0x176/0x1b0
[   87.653442][ T8811]  prepare_exit_to_usermode+0x48e/0x600
[   87.653454][ T8811]  ? syscall_return_slowpath+0xf9/0x420
[   87.653473][ T8811]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   87.653482][ T8811] RIP: 0033:0x416041
[   87.653493][ T8811] Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 1b 00 00 c3 48 83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
[   87.663252][ T8811] RSP: 002b:00007ffe6e81ce90 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
[   87.663261][ T8811] RAX: 0000000000000000 RBX: 0000000000000006 RCX: 0000000000416041
[   87.663266][ T8811] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000005
[   87.663270][ T8811] RBP: 0000000000000001 R08: 00ffffffffffffff R09: 00ffffffffffffff
[   87.663275][ T8811] R10: 00007ffe6e81cf70 R11: 0000000000000293 R12: 000000000076c920
[   87.663279][ T8811] R13: 000000000076c920 R14: 00000000000152a1 R15: 000000000076bf2c
[   87.669284][ T8811] Kernel Offset: disabled
[   87.920451][ T8811] Rebooting in 86400 seconds..

Re: [PATCH v2] sctp: fix refcount bug in sctp_wfree

[Qiujun Huang]

[ T8813] [1]put skb 0xffff888099ebbe80 back. sctp_check_transmitted, 1533
[ T8813] [1]put back to queue 0xffff888096b2c280 sctp_check_transmitted, 1683
Something wrong happens here, 0xffff888099ebbe80 not changed to newsk
[ T8813] [1]before sk 0xffff88809621e7c0 sctp_sock_migrate, 9592

cause

[ T8811] [0]skb 0xffff888099ebbe80 0xffff8880a3bb2800: truesize
131328, sk alloc 296449 sctp_wfree 9101
               real sk 0xffff88809621e7c0

it's sk is still oldsk.