[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3F128C9216C9B84BB6ED23EF16290AFB185A44A5@CRSMSX101.amr.corp.intel.com>
Date: Wed, 20 Jan 2016 18:14:23 +0000
From: "Wan, Kaike" <kaike.wan@...el.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
CC: "Eric W. Biederman" <ebiederm@...ssion.com>,
Richard Weinberger <richard.weinberger@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Thomas Graf <tgraf@...g.ch>,
Daniel Borkmann <daniel@...earbox.net>,
Ken-ichirou MATSUZAWA <chamaken@...il.com>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>,
Florian Westphal <fw@...len.de>,
netdev <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
syzkaller <syzkaller@...glegroups.com>,
Kostya Serebryany <kcc@...gle.com>,
"Alexander Potapenko" <glider@...gle.com>,
Sasha Levin <sasha.levin@...cle.com>,
"Eric Dumazet" <edumazet@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
"Fleck, John" <john.fleck@...el.com>,
"Weiny, Ira" <ira.weiny@...el.com>,
"Doug Ledford" <dledford@...hat.com>,
Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Subject: RE: net: GPF in __netlink_ns_capable
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:herbert@...dor.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 <herbert@...dor.apana.org.au> Home Page:
> http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists