linux-kernel - Re: [PATCH] idr: fix invalid ptr dereference on item delete

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: <20180518153138.459c78a83c6bada41b4b187d@linux-foundation.org>
Date:   Fri, 18 May 2018 15:31:38 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Roman Kagan <rkagan@...tuozzo.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] idr: fix invalid ptr dereference on item delete

On Fri, 18 May 2018 10:50:25 -0700 Matthew Wilcox <willy@...radead.org> wrote:

> If the radix tree underlying the IDR happens to be full and we attempt
> to remove an id which is larger than any id in the IDR, we will call
> __radix_tree_delete() with an uninitialised 'slot' pointer, at which
> point anything could happen.  This was easiest to hit with a single entry
> at id 0 and attempting to remove a non-0 id, but it could have happened
> with 64 entries and attempting to remove an id >= 64.
> 
> Fixes: 0a835c4f090a ("Reimplement IDR and IDA using the radix tree")
> Reported-by: syzbot+35666cba7f0a337e2e79@...kaller.appspotmail.com
> Debugged-by: Roman Kagan <rkagan@...tuozzo.com>
> Signed-off-by: Matthew Wilcox <mawilcox@...rosoft.com>

Neither of the changelogs I'm seeing attempt to describe the end-user
impact of the bug.  People like to know that so they can decide which
kernel version(s) need patching, so please always remember it.

Looknig at the sysbot report, the impact is at least "privileged user
can trigger a WARN", but I assume there could be worse,
as-yet-undiscovered impacts.  So I'm thinking a cc:stable is needed,
yes?