linux-kernel - Re: CVE-2023-52734: net: sched: sch: Bounds check priority

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: <ZlbIZ8bdBK4tZcBa@tiehlicka>
Date: Wed, 29 May 2024 09:30:08 +0200
From: Michal Hocko <mhocko@...e.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org,
	linux-cve-announce@...r.kernel.org,
	Kees Cook <keescook@...omium.org>
Subject: Re: CVE-2023-52734: net: sched: sch: Bounds check priority

On Tue 28-05-24 21:06:39, Greg KH wrote:
> On Tue, May 28, 2024 at 09:53:12AM +0200, Michal Hocko wrote:
> > Is this really soemthing that should be getting a CVE assigned?
> > First the fix is incomplete - 9cec2aaffe96 ("net: sched: sch: Fix off by one in htb_activate_prios()")
> 
> Incomplete fixes are still part of a fix :)

Sigh

> > Second is this even real problem? https://lore.kernel.org/all/Y9V3mBmLUcrEdrTV@pop-os.localdomain/
> > suggests it is not.
> 
> Ah, good catch, I didn't see that.  I'll go revoke this as it's not
> doing anything.

Thanks!

I wish the CVE review process would catch something like that before
issuing a CVE for it.

> > And third, WARN_ONs are considered a real deal by CVE team because
> > somebody might be running with panic_on_warn. This patch adds one!
> 
> Yes, but if you can't hit that by anything from userspace, it's not an
> issue and just dead code.  We'll have to wait for a future syzbot report
> to prove that wrong :)

I am not judging the patch itself. It is maintainers who should decide
whether this is something they want to accept.

I am questioning the decision to make it a CVE. Because if that was a
real deal then WARN_ON is something kernel CNA is considering a CVE worth
problem! So a CVE has been filed with a fix that is CVE itself.
Seriously how could this pass through the CVE review process?
-- 
Michal Hocko
SUSE Labs