linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Xin Long <lucien.xin@gmail.com>
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>,
	Vladislav Yasevich <vyasevich@gmail.com>,
	Neil Horman <nhorman@tuxdriver.com>,
	David Miller <davem@davemloft.net>,
	linux-sctp@vger.kernel.org, netdev <netdev@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	syzkaller <syzkaller@googlegroups.com>
Subject: Re: sctp: suspicious rcu_dereference_check() usage in sctp_epaddr_lookup_transport
Date: Wed, 14 Dec 2016 18:04:52 +0800	[thread overview]
Message-ID: <CADvbK_fo9j2au9Lq197bQJWxCEh7vCgStx_KoAWyQm-pubrwVg@mail.gmail.com> (raw)
In-Reply-To: <20161213213730.GA4731@localhost.localdomain>

On Wed, Dec 14, 2016 at 5:37 AM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Tue, Dec 13, 2016 at 07:07:01PM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> I am getting the following reports while running syzkaller fuzzer:
>>
>> [ INFO: suspicious RCU usage. ]
>> 4.9.0+ #85 Not tainted
>> -------------------------------
>> ./include/linux/rhashtable.h:572 suspicious rcu_dereference_check() usage!
>>
>> other info that might help us debug this:
>>
>> rcu_scheduler_active = 1, debug_locks = 0
>> 1 lock held by syz-executor1/18023:
>>  #0:  (sk_lock-AF_INET){+.+.+.}, at: [<     inline     >] lock_sock
>> include/net/sock.h:1454
>>  #0:  (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff87bb3ccf>]
>> sctp_getsockopt+0x45f/0x6800 net/sctp/socket.c:6432
>>
>> stack backtrace:
>> CPU: 2 PID: 18023 Comm: syz-executor1 Not tainted 4.9.0+ #85
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Call Trace:
>> [<     inline     >] __dump_stack lib/dump_stack.c:15
>> [<        none        >] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
>> [<        none        >] lockdep_rcu_suspicious+0x139/0x180
>> kernel/locking/lockdep.c:4448
>> [<     inline     >] __rhashtable_lookup ./include/linux/rhashtable.h:572
>> [<     inline     >] rhltable_lookup ./include/linux/rhashtable.h:660
>> [<        none        >] sctp_epaddr_lookup_transport+0x641/0x930
>> net/sctp/input.c:946
>
> I think this was introduced in the rhlist converstion. We had removed
> some rcu_read_lock() calls on sctp stack because rhashtable was already
> calling it, but then we didn't add them back when moving to rhlist.
>
> This code:
> +/* return a transport without holding it, as it's only used under sock lock */
>  struct sctp_transport *sctp_epaddr_lookup_transport(
>                                 const struct sctp_endpoint *ep,
>                                 const union sctp_addr *paddr)
>  {
>         struct net *net = sock_net(ep->base.sk);
> +       struct rhlist_head *tmp, *list;
> +       struct sctp_transport *t;
>         struct sctp_hash_cmp_arg arg = {
> -               .ep    = ep,
>                 .paddr = paddr,
>                 .net   = net,
> +               .lport = htons(ep->base.bind_addr.port),
>         };
>
> -       return rhashtable_lookup_fast(&sctp_transport_hashtable, &arg,
> -                                     sctp_hash_params);
> +       list = rhltable_lookup(&sctp_transport_hashtable, &arg,
> +                              sctp_hash_params);
>
> Had an implicit rcu_read_lock() on rhashtable_lookup_fast, but it
> doesn't on rhltable_lookup and rhltable_lookup uses _rcu calls which
> assumes we have rcu read protection.

You're right, we need to call rcu_read_lock before using rhltable_lookup.
will post a fix for it, thanks.

      reply	other threads:[~2016-12-14 10:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-13 18:07 sctp: suspicious rcu_dereference_check() usage in sctp_epaddr_lookup_transport Dmitry Vyukov
2016-12-13 21:37 ` Marcelo Ricardo Leitner
2016-12-14 10:04   ` Xin Long [this message]

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=CADvbK_fo9j2au9Lq197bQJWxCEh7vCgStx_KoAWyQm-pubrwVg@mail.gmail.com \
    --to=lucien.xin@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dvyukov@google.com \
    --cc=edumazet@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=marcelo.leitner@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=syzkaller@googlegroups.com \
    --cc=vyasevich@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).