The problem was caused by the RDMA_NL_LS_OP_RESOLVE request (not response) packet sent by the user application, which falls through the netlink_dump path and eventually calls ib_nl_handle_resp() with a new skb with uninitialized control block. Checking the NETLINK_CB(skb).sk before calling netlink_capable() will fix the problem.
I will submit a patch soon. Kaike > -----Original Message----- > From: Herbert Xu [mailto:herb...@gondor.apana.org.au] > Sent: Wednesday, January 20, 2016 10:00 AM > To: Wan, Kaike > Cc: Eric W. Biederman; Richard Weinberger; David S. Miller; Thomas Graf; > Daniel Borkmann; Ken-ichirou MATSUZAWA; Nicolas Dichtel; Florian > Westphal; netdev; LKML; syzkaller; Kostya Serebryany; Alexander Potapenko; > Sasha Levin; Eric Dumazet; Dmitry Vyukov; Fleck, John; Weiny, Ira; Doug > Ledford; Jason Gunthorpe > Subject: Re: net: GPF in __netlink_ns_capable > > On Wed, Jan 20, 2016 at 02:35:59PM +0000, Wan, Kaike wrote: > > >From the code (netlink_dump() in net/netlink/af_netlink.c), it shows that a > skb is allocated without initializing the skb->cb[] field, which will cause > oops > if netlink_capable() is called with the duplicate skb. This will happen if the > netlink_dump_start() path is followed (in ibnl_rcv_msg() in > drivers/infiniband/core/netlink.c). However, for the IB netlink local service, > we handle only request RDMA_NL_LS_OP_SET_TIMEOUT and response to > RDMA_NL_LS_OP_RESOLVE, which directly call the registered dump function > (ib_nl_handle_resolve_resp() and ib_nl_handle_resolve_resp()). See the > following snippet: > > You'll find a reproducer in the original email: > > http://lkml.iu.edu/hypermail/linux/kernel/1601.1/06505.html > > Cheers, > -- > Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: > http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
