[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZfBwuDyzLl5M0mhC@bombadil.infradead.org>
Date: Tue, 12 Mar 2024 08:11:52 -0700
From: Luis Chamberlain <mcgrof@...nel.org>
To: Michal Hocko <mhocko@...e.com>
Cc: Lee Jones <lee@...nel.org>, cve@...nel.org,
linux-kernel@...r.kernel.org,
Joel Granados <j.granados@...sung.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: CVE-2023-52596: sysctl: Fix out of bounds access for empty
sysctl registers
On Tue, Mar 12, 2024 at 10:45:28AM +0100, Michal Hocko wrote:
> On Tue 12-03-24 09:17:30, Lee Jones wrote:
> [...]
> > > Backporting this is fine, but wouldn't fix an issue unless an external
> > > module had empty sysctls. And exploiting this is not possible unless
> > > you purposely build an external module which could end up with empty
> > > sysctls.
>
> Thanks for the clarification Luis!
>
> > Thanks for the amazing explanation Luis.
> >
> > If I'm reading this correctly, an issue does exist, but an attacker
> > would have to lay some foundations before it could be triggered. Sounds
> > like loading of a malicious or naive module would be enough.
>
> If the bar is set as high as a kernel module to create and empty sysctl
> directory then I think it is safe to say that the security aspect is
> mostly moot. There are much simpler ways to attack the system if you are
> able to load a kernel module.
Indeed, a simple BUG_ON(1) on external modules cannot possible be a
source of a CVE. And so this becomes BUG_ON(when_sysctl_empty()) where
when_sysctl_empty() is hypotethical and I think the source of this
question for CVE. Today's that not at boot time or dynamically with any
linux kernel sources released, and so its only possible if:
a) As Joel indicated if you backported an empty sysctl array
(which would be unless you carried all the infrastructure to support it).
b) an external module has an empty sysctl
HTH.
Luis
Powered by blists - more mailing lists