linux-kernel - Re: [PATCH 4.19 000/220] 4.19.86-stable review

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))