lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 25 Aug 2021 14:26:29 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Haakon Bugge <haakon.bugge@...cle.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 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.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ