2024-03-05 18:45:17

by Michal Hocko

[permalink] [raw]
Subject: Re: CVE-2021-47090: mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page()

On Mon 04-03-24 19:11:17, Greg KH wrote:
> Description
> ===========
>
> In the Linux kernel, the following vulnerability has been resolved:
>
> mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page()

I would like to dispute this CVE. The interface is behind CAP_SYSADMIN
and allowing access to this to any untrusted party is risking serious
troubles. This is a testing only feature.

--
Michal Hocko
SUSE Labs


2024-03-05 22:21:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: CVE-2021-47090: mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page()

On Tue, Mar 05, 2024 at 07:45:04PM +0100, Michal Hocko wrote:
> On Mon 04-03-24 19:11:17, Greg KH wrote:
> > Description
> > ===========
> >
> > In the Linux kernel, the following vulnerability has been resolved:
> >
> > mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page()
>
> I would like to dispute this CVE. The interface is behind CAP_SYSADMIN
> and allowing access to this to any untrusted party is risking serious
> troubles. This is a testing only feature.

This fixes a weakness in the kernel, one that is allowed to crash it,
why isn't that a good thing to have a CVE entry for? Are we saying that
all VM_BUG_ON_PAGE() instances should not be accounted for? That's not
what the config option for CONFIG_DEBUG_VM says, it just says it will
affect performance.

Also /sys/devices/system/memory/soft_offline_page doesn't say "can crash
the system", so it should work properly, even if an admin uses it, it
shouldn't shut the box down.

confused,

greg k-h

2024-03-06 08:16:14

by Michal Hocko

[permalink] [raw]
Subject: Re: CVE-2021-47090: mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page()

On Tue 05-03-24 22:20:17, Greg KH wrote:
> On Tue, Mar 05, 2024 at 07:45:04PM +0100, Michal Hocko wrote:
> > On Mon 04-03-24 19:11:17, Greg KH wrote:
> > > Description
> > > ===========
> > >
> > > In the Linux kernel, the following vulnerability has been resolved:
> > >
> > > mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page()
> >
> > I would like to dispute this CVE. The interface is behind CAP_SYSADMIN
> > and allowing access to this to any untrusted party is risking serious
> > troubles. This is a testing only feature.
>
> This fixes a weakness in the kernel, one that is allowed to crash it,
> why isn't that a good thing to have a CVE entry for? Are we saying that
> all VM_BUG_ON_PAGE() instances should not be accounted for? That's not
> what the config option for CONFIG_DEBUG_VM says, it just says it will
> affect performance.

I wouldn't personaly recommend anybody using CONFIG_DEBUG_VM=y in
production. But I am not questioning if somebody does that. This is
not really what I am objecting to. Hwpoisoning or soft offlining is not
aimed for other than testing purposes. Things can go wrong during
these oprations.

If you insist this still qualifies as a vulnaribility/weakness fix then
I would propose a new category pig-with-a-lipstick-CVE.

> Also /sys/devices/system/memory/soft_offline_page doesn't say "can crash
> the system", so it should work properly, even if an admin uses it, it
> shouldn't shut the box down.

I agree that Documentation/ABI/testing/sysfs-memory-page-offline would
benefit from an update. Documentation/admin-guide/mm/memory-hotplug.rst
is explicit about this being a testing feature.
--
Michal Hocko
SUSE Labs

2024-03-06 08:40:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: CVE-2021-47090: mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page()

On Wed, Mar 06, 2024 at 09:06:42AM +0100, Michal Hocko wrote:
> On Tue 05-03-24 22:20:17, Greg KH wrote:
> > On Tue, Mar 05, 2024 at 07:45:04PM +0100, Michal Hocko wrote:
> > > On Mon 04-03-24 19:11:17, Greg KH wrote:
> > > > Description
> > > > ===========
> > > >
> > > > In the Linux kernel, the following vulnerability has been resolved:
> > > >
> > > > mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page()
> > >
> > > I would like to dispute this CVE. The interface is behind CAP_SYSADMIN
> > > and allowing access to this to any untrusted party is risking serious
> > > troubles. This is a testing only feature.
> >
> > This fixes a weakness in the kernel, one that is allowed to crash it,
> > why isn't that a good thing to have a CVE entry for? Are we saying that
> > all VM_BUG_ON_PAGE() instances should not be accounted for? That's not
> > what the config option for CONFIG_DEBUG_VM says, it just says it will
> > affect performance.
>
> I wouldn't personaly recommend anybody using CONFIG_DEBUG_VM=y in
> production. But I am not questioning if somebody does that. This is
> not really what I am objecting to. Hwpoisoning or soft offlining is not
> aimed for other than testing purposes. Things can go wrong during
> these oprations.

Agreed, things can go wrong, but people use them for "reasons" otherwise
we wouldn't have those options in the kernel at all. Because of that,
this "fix for a weakness" was given a CVE, that's all.

Again, we do not dictate use case, or severity at all, that's not our
role.

> If you insist this still qualifies as a vulnaribility/weakness fix then
> I would propose a new category pig-with-a-lipstick-CVE.
>
> > Also /sys/devices/system/memory/soft_offline_page doesn't say "can crash
> > the system", so it should work properly, even if an admin uses it, it
> > shouldn't shut the box down.
>
> I agree that Documentation/ABI/testing/sysfs-memory-page-offline would
> benefit from an update. Documentation/admin-guide/mm/memory-hotplug.rst
> is explicit about this being a testing feature.

The fact that I didn't even notice that is kind of proof that maybe
others might also miss it :)

thanks,

greg k-h

2024-03-06 09:03:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: CVE-2021-47090: mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page()

On Wed, Mar 06, 2024 at 09:06:42AM +0100, Michal Hocko wrote:
> If you insist this still qualifies as a vulnaribility/weakness fix then
> I would propose a new category pig-with-a-lipstick-CVE.

We don't get to pick "categories" for CVEs, that's what other people do,
and I wish them the best of luck! :)

thanks,

greg k-h