All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Xin Long <lucien.xin@gmail.com>
Cc: xietangxin <xietangxin@h-partners.com>,
	syzbot+80dfcb1a2235b3efc877@syzkaller.appspotmail.com,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Simon Horman <horms@kernel.org>, Jakub Kicinski <kuba@kernel.org>,
	marcelo.leitner@gmail.com, Paolo Abeni <pabeni@redhat.com>,
	linux-kernel@vger.kernel.org, linux-sctp@vger.kernel.org,
	netdev@vger.kernel.org, syzkaller-bugs@googlegroups.com,
	gaoxingwang <gaoxingwang1@huawei.com>,
	huyizhen2@huawei.com
Subject: Re: [syzbot] [sctp?] WARNING: refcount bug in sctp_transport_put (6)
Date: Tue, 1 Sep 2026 15:35:24 +0100	[thread overview]
Message-ID: <20260901153524.3e92df3a@pumpkin> (raw)
In-Reply-To: <CADvbK_eY4S1HbdNHuNq9b=Va-TA_6rNFvnCvtOUZ0sF-AWN67A@mail.gmail.com>

On Tue, 1 Sep 2026 09:45:42 -0400
Xin Long <lucien.xin@gmail.com> wrote:

> On Mon, Aug 31, 2026 at 11:47 PM xietangxin <xietangxin@h-partners.com> wrote:
> >
> > Hi,
> >
> > I have analyzed this issue and successfully reproduced locally.
> > The race occurs between the timer callback (`sctp_generate_heartbeat_event`) and
> > the transport cleanup path (`sctp_transport_free`):
> >
> > Task 1(Timer Softirq)               Task 2(sctp_transport_free)
> > ==========================              ===============================
> > sctp_generate_heartbeat_event()
> >   refcnt = 2
> >
> >   bh_lock_sock(sk)
> >   sock_owned_by_user(sk)
> >   mod_timer(&hb_timer) -> returns 0
> >                                           sctp_transport_free()
> >                                             transport->dead = 1
> >                                             del_timer(&hb_timer) -> returns 1!
> >                                               sctp_transport_put() (2 -> 1)
> >                                             sctp_transport_put() (1 -> 0)
> >                                               sctp_transport_destroy()
> >
> >   sctp_transport_hold()  
> >     -> refcnt is 0, increment fails  
> 
> This should not be 0, as the transport must hold a refcnt to start the
> hb_timer.

Isn't there one hold sctp_generate_heartbeat_event() and a second for
whatever 'task 2' is doing.
When hb_timer is started it is given another hold (does it actually need one??).
So when hb_timer is deleted it's hold is removed.
But the del_timer() is happening before the the extra hold is obtained.

The RHS (task 2) would need to hold bh_lock_sock().

Try giving sctp_generate_heartbeat_event() two holds.

David


> 
> Also, the delay below is under bh_lock_sock(), so it should not be the
> real cause of the issue.
> 
> Could you share the PoC for this issue?
> 
> Thanks.
> 
> >   out_unlock:
> >     sctp_transport_put() (0 -> -1)  
> >     -> refcount underflow warning!  
> >
> >
> >
> > Adding a small delay  after `mod_timer()` increases the reproduction rate:
> >
> > --- a/net/sctp/sm_sideeffect.c
> > +++ b/net/sctp/sm_sideeffect.c
> > @@ -373,8 +373,10 @@ void sctp_generate_heartbeat_event(struct timer_list *t)
> >                 pr_debug("%s: sock is busy\n", __func__);
> >
> >                 /* Try again later.  */
> > -               if (!mod_timer(&transport->hb_timer, jiffies + (HZ/20)))
> > +               if (!mod_timer(&transport->hb_timer, jiffies + (HZ/20))) {
> > +                       mdelay(1);
> >                         sctp_transport_hold(transport);
> > +               }
> >                 goto out_unlock;
> >         }
> >
> > Any feedback or guidance would be greatly appreciated.
> >
> > --
> > Best regards,
> > Tangxin Xie
> >  
> 


  reply	other threads:[~2026-09-01 14:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13  8:59 [syzbot] [sctp?] WARNING: refcount bug in sctp_transport_put (6) syzbot
2026-09-01  3:47 ` xietangxin
2026-09-01 13:45   ` Xin Long
2026-09-01 14:35     ` David Laight [this message]
2026-09-01 15:06       ` Xin Long
2026-09-01 21:46         ` David Laight
2026-09-03  3:22           ` xietangxin
2026-09-03 14:00             ` Xin Long
2026-09-05  1:17               ` xietangxin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260901153524.3e92df3a@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gaoxingwang1@huawei.com \
    --cc=horms@kernel.org \
    --cc=huyizhen2@huawei.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=lucien.xin@gmail.com \
    --cc=marcelo.leitner@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=syzbot+80dfcb1a2235b3efc877@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=xietangxin@h-partners.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.