On Thu, Apr 19, 2018 at 2:55 PM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > On Thu, Apr 19, 2018 at 2:32 AM, DaeRyong Jeong <threeear...@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/