LKML Archive on
help / color / mirror / Atom feed
From: Haakon Bugge <>
To: Jason Gunthorpe <>
Cc: Divya Indi <>,
	LKML <>,
	OFED mailing list <>,
	Kaike Wan <>,
	Gerd Rausch <>,
	Srinivas Eeda <>,
	Rama Nichanamatlu <>,
	Doug Ledford <>,
	Leon Romanovsky <>
Subject: Re: [PATCH v4] IB/sa: Resolving use-after-free in ib_nl_send_msg
Date: Mon, 23 Aug 2021 16:54:16 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> On 8 Jul 2020, at 03:12, Jason Gunthorpe <> wrote:
> On Tue, Jul 07, 2020 at 06:05:02PM -0700, Divya Indi wrote:
>> Thanks Jason.
>> Appreciate your help and feedback for fixing this issue.
>> Would it be possible to access the edited version of the patch?
>> If yes, please share a pointer to the same.

Hi Jason,

At first glanse, this commit calls rdma_nl_multicast() whilst holding a spinlock. Since rdma_nl_multicast() is called with a gfp_flag parameter, one could assume it supports an atomic context. rdma_nl_multicast() ends up in netlink_broadcast_filtered(). This function calls netlink_lock_table(), which calls read_unlock_irqrestore(), which ends up calling _raw_read_unlock_irqrestore(). And here preempt_enable() is called :-(

Now, this could be fixed by calling rdma_nl_multicast() outside the spinlock and instead insert the request into the timeout list in a sorted fashion.

But the main problem here is that ib_nl_make_request() can be called from an atomic context, for example from:

neigh_refresh_path()  (takes a spin lock) ==>
    path_rec_start() ==>
        ib_sa_path_rec_get() ==>
            send_mad() ==>
                ib_nl_make_request() ==>

Here's the stack trace (not newest upstream, but I pretty sure the same problem is there):

send_mad+0x3d2/0x590 [ib_core]
? ipoib_start_xmit+0x6a0/0x6a0 [ib_ipoib]
ib_sa_path_rec_get+0x223/0x4d0 [ib_core]
? ipoib_start_xmit+0x6a0/0x6a0 [ib_ipoib]
? do_IRQ+0x59/0xe3
path_rec_start+0xa3/0x140 [ib_ipoib]
? ipoib_start_xmit+0x6a0/0x6a0 [ib_ipoib]
ipoib_start_xmit+0x2b0/0x6a0 [ib_ipoib]
? __alloc_skb+0xa1/0x289
? try_to_wake_up+0x59/0x4f1
? wake_up_worker+0x28/0x2b
? __slab_free+0x9b/0x2ba
? dma_get_required_mask+0x28/0x31
? iommu_should_identity_map+0x52/0xdb
? iommu_no_mapping+0x4a/0xd1
ipoib_ib_handle_rx_wc+0x1ca/0x520 [ib_ipoib]
ipoib_poll+0xcd/0x150 [ib_ipoib]
rdma_nl_multicast+0x22/0x30 [ib_core]
send_mad+0x3e5/0x590 [ib_core]
? cma_bind_port+0x90/0x90 [rdma_cm]
ib_sa_path_rec_get+0x223/0x4d0 [ib_core]
? cma_bind_port+0x90/0x90 [rdma_cm]
? ring_buffer_lock_reserve+0x120/0x34d
? kmem_cache_alloc_trace+0x16f/0x1cd
rdma_resolve_route+0x287/0x810 [rdma_cm]
? cma_bind_port+0x90/0x90 [rdma_cm]
rds_rdma_cm_event_handler_cmn+0x311/0x7d0 [rds_rdma]
rds_rdma_cm_event_handler_worker+0x22/0x30 [rds_rdma]

How shall this be attacked?

Thxs, Håkon


  reply	other threads:[~2021-08-23 16:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24  2:13 Divya Indi
2020-06-25 10:09 ` Leon Romanovsky
2020-06-25 17:11   ` Divya Indi
2020-06-25 19:00     ` Leon Romanovsky
2020-07-02 19:07 ` Jason Gunthorpe
2020-07-08  1:05   ` Divya Indi
2020-07-08  1:12     ` Jason Gunthorpe
2021-08-23 16:54       ` Haakon Bugge [this message]
2021-08-25 17:26         ` Jason Gunthorpe
2021-08-26 15:25           ` Haakon Bugge

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v4] IB/sa: Resolving use-after-free in ib_nl_send_msg' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).