[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87E23BD6-857D-4A87-93EF-D2098535F997@oracle.com>
Date: Thu, 26 Aug 2021 15:25:00 +0000
From: Haakon Bugge <haakon.bugge@...cle.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: Divya Indi <divya.indi@...cle.com>,
LKML <linux-kernel@...r.kernel.org>,
OFED mailing list <linux-rdma@...r.kernel.org>,
Kaike Wan <kaike.wan@...el.com>,
Gerd Rausch <gerd.rausch@...cle.com>,
Srinivas Eeda <srinivas.eeda@...cle.com>,
Rama Nichanamatlu <rama.nichanamatlu@...cle.com>,
Doug Ledford <dledford@...hat.com>,
Leon Romanovsky <leon@...nel.org>
Subject: Re: [PATCH v4] IB/sa: Resolving use-after-free in ib_nl_send_msg
> On 25 Aug 2021, at 19:26, Jason Gunthorpe <jgg@...dia.com> wrote:
>
> On Mon, Aug 23, 2021 at 04:54:16PM +0000, Haakon Bugge wrote:
>>
>>
>>> On 8 Jul 2020, at 03:12, Jason Gunthorpe <jgg@...dia.com> 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.
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?h=for-rc&id=f427f4d6214c183c474eeb46212d38e6c7223d6a
>>
>> 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 :-(
>
> I don't understand. This:
>
> unsigned long flags;
>
> read_lock_irqsave(&nl_table_lock, flags);
> atomic_inc(&nl_table_users);
> read_unlock_irqrestore(&nl_table_lock, flags);
>
> Is perfectly fine in an atomic context.
>
> preempt_enable is implemented as a nesting counter, so it is fine to
> call it from inside an atomic region so long as it is balanced.
You are right. As I said, the stack trace was from a UEK kernel. It turns out, I overlooked commit 2dce224f469f ("netns: protect netns ID lookups with RCU"), which replaces spin_{lock,unlock}_bh with rcu_read_{lock,unlock} in peernet2id().
This commit fixed this bug un-intentionally, I would say! So, this bug has been present in kernels until v5.5-rc7.
Sorry for the noise!
HÃ¥kon
Powered by blists - more mailing lists