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]
Message-ID: <20191122170534.GV20752@bombadil.infradead.org>
Date:   Fri, 22 Nov 2019 09:05:34 -0800
From:   Matthew Wilcox <willy@...radead.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Guenter Roeck <linux@...ck-us.net>, linux-kernel@...r.kernel.org,
        torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
        shuah@...nel.org, patches@...nelci.org,
        ben.hutchings@...ethink.co.uk, lkft-triage@...ts.linaro.org,
        stable@...r.kernel.org
Subject: Re: [PATCH 4.19 000/220] 4.19.86-stable review

On Fri, Nov 22, 2019 at 04:16:31PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Nov 22, 2019 at 06:47:05AM -0800, Guenter Roeck wrote:
> > On 11/22/19 2:26 AM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.19.86 release.
> > > There are 220 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > > 
> > > Responses should be made by Sun, 24 Nov 2019 09:59:19 +0000.
> > > Anything received after that time might be too late.
> > > 
> > 
> > I see the following warning (at least for arm64, ppc64, and x86_64).
> > This seems to be caused by "idr: Fix idr_get_next race with idr_remove".
> > v4.14.y is also affected. Mainline and v5.3.y are not affected.

That makes sense; the code in question is different after 4.19.
Thanks for the report; it's very clear.

> Willy, this looks like something from your patch, is it to be expected?

It's harmless; the problem is that we can't check whether the dereference
is safe.  The caller isn't holding the RCU lock, and the IDR code doesn't
know what lock is being held to make this dereference safe.  Do you want
a changelog for this oneliner which disables the checking?

diff --git a/lib/idr.c b/lib/idr.c
index 49e7918603c7..6ff3b1c36e0a 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -237,7 +237,7 @@ void *idr_get_next(struct idr *idr, int *nextid)
 
 	id = (id < base) ? 0 : id - base;
 	radix_tree_for_each_slot(slot, &idr->idr_rt, &iter, id) {
-		entry = radix_tree_deref_slot(slot);
+		entry = rcu_dereference_raw(*slot);
 		if (!entry)
 			continue;
 		if (!radix_tree_deref_retry(entry))

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ