[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190709192854.GA14462@ziepe.ca>
Date: Tue, 9 Jul 2019 16:28:54 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Dag Moxnes <dag.moxnes@...cle.com>
Cc: dledford@...hat.com, leon@...nel.org, parav@...lanox.com,
linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] RDMA/core: Fix race when resolving IP address
On Tue, Jul 09, 2019 at 01:50:26PM +0200, Dag Moxnes wrote:
> Use the neighbour lock when copying the MAC address from the neighbour
> data struct in dst_fetch_ha.
>
> When not using the lock, it is possible for the function to race with
> neigh_update(), causing it to copy an torn MAC address:
>
> rdma_resolve_addr()
> rdma_resolve_ip()
> addr_resolve()
> addr_resolve_neigh()
> fetch_ha()
> dst_fetch_ha()
> memcpy(dev_addr->dst_dev_addr, n->ha, MAX_ADDR_LEN)
>
> and
>
> net_ioctl()
> arp_ioctl()
> arp_rec_delete()
> arp_invalidate()
> neigh_update()
> __neigh_update()
> memcpy(&neigh->ha, lladdr, dev->addr_len)
>
> It is possible to provoke this error by calling rdma_resolve_addr() in a
> tight loop, while deleting the corresponding ARP entry in another tight
> loop.
>
> Fixes: 51d45974515c ("infiniband: addr: Consolidate code to fetch neighbour hardware address from dst.")
> Signed-off-by: Dag Moxnes <dag.moxnes@...cle.com>
> Signed-off-by: HÃ¥kon Bugge <haakon.bugge@...cle.com>
> Reviewed-by: Parav Pandit <parav@...lanox.com>
> Signed-off-by: Jason Gunthorpe <jgg@...lanox.com>
> ---
> drivers/infiniband/core/addr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to for-next, thanks
Jason
Powered by blists - more mailing lists