From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: DaeRyong Jeong <threeearcat@gmail.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>,
Byoungyoung Lee <byoungyoung@purdue.edu>,
LKML <linux-kernel@vger.kernel.org>,
Kyungtae Kim <kt0755@gmail.com>,
Linux Kernel Network Developers <netdev@vger.kernel.org>,
Willem de Bruijn <willemb@google.com>
Subject: Re: WARNING in refcount_dec
Date: Mon, 23 Apr 2018 17:38:24 -0400 [thread overview]
Message-ID: <CAF=yD-JJeWSLJytyj+j_e+r2JRoCq=jpWsDC7psdft-QjM=20Q@mail.gmail.com> (raw)
In-Reply-To: <CAF=yD-JR1Bg1FLat41Uua9vi1-ALyuQttChAWyWz0Yx6_01_BA@mail.gmail.com>
On Thu, Apr 19, 2018 at 2:55 PM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
> On Thu, Apr 19, 2018 at 2:32 AM, DaeRyong Jeong <threeearcat@gmail.com> wrote:
>> Hello.
>> We have analyzed the cause of the crash in v4.16-rc3, WARNING in refcount_dec,
>> which is found by RaceFuzzer (a modified version of Syzkaller).
>>
>> Since struct packet_sock's member variables, running, has_vnet_hdr, origdev
>> and auxdata are declared as bitfields, accessing these variables can race if
>> there is no synchronization mechanism.
>
> Great catch.
>
> These fields po->{running, auxdata, origdev, has_vnet_hdr} are
> accessed without a uniform locking strategy.
>
> po->running is always accessed with po->bind_lock held (with the
> exception of reading in packet_seq_show, but that is best effort).
>
> That is the only field written to outside setsockopt. If it is moved to
> a separate word, it will no longer interfere with the others.
>
> The other fields are read lockless in the various recv and send
> functions, but only set in setsockopt. We've had enough
> locking bugs around setsockopt that I suggest we wrap all of
> those in lock_sock, like the example I gave before for
> has_vnet_hdr.
Sent http://patchwork.ozlabs.org/patch/903190/
prev parent reply other threads:[~2018-04-23 21:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-28 5:19 WARNING in refcount_dec Byoungyoung Lee
2018-03-28 19:03 ` Byoungyoung Lee
2018-03-28 23:16 ` Cong Wang
2018-04-01 7:38 ` Willem de Bruijn
2018-04-03 4:12 ` DaeRyong Jeong
2018-04-19 6:32 ` DaeRyong Jeong
2018-04-19 18:55 ` Willem de Bruijn
2018-04-23 21:38 ` Willem de Bruijn [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='CAF=yD-JJeWSLJytyj+j_e+r2JRoCq=jpWsDC7psdft-QjM=20Q@mail.gmail.com' \
--to=willemdebruijn.kernel@gmail.com \
--cc=byoungyoung@purdue.edu \
--cc=kt0755@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=threeearcat@gmail.com \
--cc=willemb@google.com \
--cc=xiyou.wangcong@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 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.