Hi,
this seems like another example of a reasonable fix with a very dubious
CVE IMHO. Allowing access to /sys/kernel/debug/acpi/custom_method to
anybody but trusted actor is a huge security problem on its own. I
really fail to see any value marking this clear bug fix as security
related.
On Tue 27-02-24 19:47:26, Greg KH wrote:
> Description
> ===========
>
> In the Linux kernel, the following vulnerability has been resolved:
>
> ACPI: custom_method: fix potential use-after-free issue
>
> In cm_write(), buf is always freed when reaching the end of the
> function. If the requested count is less than table.length, the
> allocated buffer will be freed but subsequent calls to cm_write() will
> still try to access it.
>
> Remove the unconditional kfree(buf) at the end of the function and
> set the buf to NULL in the -EINVAL error path to match the rest of
> function.
>
> The Linux kernel CVE team has assigned CVE-2021-46966 to this issue.
>
>
> Affected and fixed versions
> ===========================
>
> Issue introduced in 4.4.195 with commit 4bda2b79a9d0 and fixed in 4.4.269 with commit 1d53ca5d1310
> Issue introduced in 4.9.195 with commit 5c12dadcbef8 and fixed in 4.9.269 with commit 8b04d57f30ca
> Issue introduced in 4.14.147 with commit 35b88a10535e and fixed in 4.14.233 with commit 90575d1d9311
> Issue introduced in 4.19.77 with commit e4467fb6ef54 and fixed in 4.19.191 with commit a5b26a2e362f
> Issue introduced in 5.4 with commit 03d1571d9513 and fixed in 5.4.118 with commit 72814a94c38a
> Issue introduced in 5.4 with commit 03d1571d9513 and fixed in 5.10.36 with commit 62dc2440ebb5
> Issue introduced in 5.4 with commit 03d1571d9513 and fixed in 5.11.20 with commit f16737caf41f
> Issue introduced in 5.4 with commit 03d1571d9513 and fixed in 5.12.3 with commit b7a5baaae212
> Issue introduced in 5.4 with commit 03d1571d9513 and fixed in 5.13 with commit e483bb9a991b
>
> Please see https://www.kernel.org or a full list of currently supported
> kernel versions by the kernel community.
>
> Unaffected versions might change over time as fixes are backported to
> older supported kernel versions. The official CVE entry at
> https://cve.org/CVERecord/?id=CVE-2021-46966
> will be updated if fixes are backported, please check that for the most
> up to date information about this issue.
>
>
> Affected files
> ==============
>
> The file(s) affected by this issue are:
> drivers/acpi/custom_method.c
>
>
> Mitigation
> ==========
>
> The Linux kernel CVE team recommends that you update to the latest
> stable kernel version for this, and many other bugfixes. Individual
> changes are never tested alone, but rather are part of a larger kernel
> release. Cherry-picking individual commits is not recommended or
> supported by the Linux kernel community at all. If however, updating to
> the latest release is impossible, the individual changes to resolve this
> issue can be found at these commits:
> https://git.kernel.org/stable/c/1d53ca5d131074c925ce38361fb0376d3bf7e394
> https://git.kernel.org/stable/c/8b04d57f30caf76649d0567551589af9a66ca9be
> https://git.kernel.org/stable/c/90575d1d9311b753cf1718f4ce9061ddda7dfd23
> https://git.kernel.org/stable/c/a5b26a2e362f572d87e9fd35435680e557052a17
> https://git.kernel.org/stable/c/72814a94c38a33239793f7622cec6ace1e540c4b
> https://git.kernel.org/stable/c/62dc2440ebb552aa0d7f635e1697e077d9d21203
> https://git.kernel.org/stable/c/f16737caf41fc06cfe6e49048becb09657074d4b
> https://git.kernel.org/stable/c/b7a5baaae212a686ceb812c32fceed79c03c0234
> https://git.kernel.org/stable/c/e483bb9a991bdae29a0caa4b3a6d002c968f94aa
--
Michal Hocko
SUSE Labs
On Wed, Feb 28, 2024 at 05:14:22PM +0100, Michal Hocko wrote:
> Hi,
> this seems like another example of a reasonable fix with a very dubious
> CVE IMHO. Allowing access to /sys/kernel/debug/acpi/custom_method to
> anybody but trusted actor is a huge security problem on its own. I
> really fail to see any value marking this clear bug fix as security
> related.
It was picked because it was a use-after-free fix, AND it is part of the
"import the GSD database into the CVE database" that the CVE project
asked us to do.
thanks,
greg k-h
On Thu 29-02-24 06:22:34, Greg KH wrote:
> On Wed, Feb 28, 2024 at 05:14:22PM +0100, Michal Hocko wrote:
> > Hi,
> > this seems like another example of a reasonable fix with a very dubious
> > CVE IMHO. Allowing access to /sys/kernel/debug/acpi/custom_method to
> > anybody but trusted actor is a huge security problem on its own. I
> > really fail to see any value marking this clear bug fix as security
> > related.
>
> It was picked because it was a use-after-free fix, AND it is part of the
> "import the GSD database into the CVE database" that the CVE project
> asked us to do.
OK I see. So now, does it make any sense to consider a bug fix in a
security sensitive interface (that is even locked down) a security fix?
--
Michal Hocko
SUSE Labs
On Thu, Feb 29, 2024 at 09:30:12AM +0100, Michal Hocko wrote:
> On Thu 29-02-24 06:22:34, Greg KH wrote:
> > On Wed, Feb 28, 2024 at 05:14:22PM +0100, Michal Hocko wrote:
> > > Hi,
> > > this seems like another example of a reasonable fix with a very dubious
> > > CVE IMHO. Allowing access to /sys/kernel/debug/acpi/custom_method to
> > > anybody but trusted actor is a huge security problem on its own. I
> > > really fail to see any value marking this clear bug fix as security
> > > related.
> >
> > It was picked because it was a use-after-free fix, AND it is part of the
> > "import the GSD database into the CVE database" that the CVE project
> > asked us to do.
>
> OK I see. So now, does it make any sense to consider a bug fix in a
> security sensitive interface (that is even locked down) a security fix?
Yes, I would think so! If you see any that we have not marked for a
CVE, please let us know and we will be glad to assign them.
Again, we do not always know if things are "locked down" or not, as
everyone uses our codebase in different ways (we don't have the benefit
of a *BSD which does dictate the use cases in ways we can not).
If your systems "lock this down" and prevent access to anyone you do not
trust, then wonderful, you aren't vulnerable to this specific issue at
all and you can just ignore it!
But for other systems that DO allow access to debugfs, this might be a
good idea to address.
thanks,
greg k-h