Consultation on backport 97e3d26b5e5f("x86/mm: Randomize per-cpu entry area") to stable

Consultation on backport 97e3d26b5e5f("x86/mm: Randomize per-cpu entry area") to stable

[Tong Tiangen]

Hi peter:

Do you have any plans to backport this patch[1] to the stable branch of 
the lower version, such as 4.19.y ?
When I try to backport this patch to 5.10.y, I met some KASAN[2] and 
KASLR[3] related issues. Although they were finally solved, there were 
still some detours in the process.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=97e3d26b5e5f371b3ee223d94dd123e6c442ba80
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f148f3318140035e87decc1214795ff0755757b
[3]

Best Regards,
Tong

.

Re: Consultation on backport 97e3d26b5e5f("x86/mm: Randomize per-cpu entry area") to stable

[Tong Tiangen]

My fault, the third patch link is missing:)

[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4150779e60fb6c49be25572596b2cdfc5d46a09

Best Regards,
Tong

.

在 2023/2/21 15:19, Tong Tiangen 写道:
> Hi peter:
> 
> Do you have any plans to backport this patch[1] to the stable branch of 
> the lower version, such as 4.19.y ?
> When I try to backport this patch to 5.10.y, I met some KASAN[2] and 
> KASLR[3] related issues. Although they were finally solved, there were 
> still some detours in the process.
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=97e3d26b5e5f371b3ee223d94dd123e6c442ba80 
> 
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f148f3318140035e87decc1214795ff0755757b 
> 
> [3]
> 
> Best Regards,
> Tong
> 
> .

Re: Consultation on backport 97e3d26b5e5f("x86/mm: Randomize per-cpu entry area") to stable

[Greg KH]

On Tue, Feb 21, 2023 at 03:19:05PM +0800, Tong Tiangen wrote:
> Hi peter:
> 
> Do you have any plans to backport this patch[1] to the stable branch of the
> lower version, such as 4.19.y ?

Why?  That is a new feature for 6.2 why would it be needed to fix
anything in really old kernels?

> When I try to backport this patch to 5.10.y, I met some KASAN[2] and
> KASLR[3] related issues. Although they were finally solved, there were still
> some detours in the process.

Send your series of backports to the list for review please if they
match the stable kernel rules.

But why can't you just use the 6.2 kernel instead of something obsolete
like 4.19?

thanks,

greg k-h

Re: Consultation on backport 97e3d26b5e5f("x86/mm: Randomize per-cpu entry area") to stable

[Tong Tiangen]

在 2023/2/21 15:30, Greg KH 写道:
> On Tue, Feb 21, 2023 at 03:19:05PM +0800, Tong Tiangen wrote:
>> Hi peter:
>>
>> Do you have any plans to backport this patch[1] to the stable branch of the
>> lower version, such as 4.19.y ?
> 
> Why?  That is a new feature for 6.2 why would it be needed to fix
> anything in really old kernels?

Hi Greg:

This patch fix CVE-2023-0597[1], this CVE report a flaw possibility of 
memory leak. And this is important for some products using this stable 
version.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2165926

> 
>> When I try to backport this patch to 5.10.y, I met some KASAN[2] and
>> KASLR[3] related issues. Although they were finally solved, there were still
>> some detours in the process.
> 
> Send your series of backports to the list for review please if they
> match the stable kernel rules.

OK.

> 
> But why can't you just use the 6.2 kernel instead of something obsolete
> like 4.19?
> 
> thanks,
> 
> greg k-h
> .

Thanks.
Tong
.

Re: Consultation on backport 97e3d26b5e5f("x86/mm: Randomize per-cpu entry area") to stable

[Greg KH]

On Tue, Feb 21, 2023 at 03:46:27PM +0800, Tong Tiangen wrote:
> 
> 
> 在 2023/2/21 15:30, Greg KH 写道:
> > On Tue, Feb 21, 2023 at 03:19:05PM +0800, Tong Tiangen wrote:
> > > Hi peter:
> > > 
> > > Do you have any plans to backport this patch[1] to the stable branch of the
> > > lower version, such as 4.19.y ?
> > 
> > Why?  That is a new feature for 6.2 why would it be needed to fix
> > anything in really old kernels?
> 
> Hi Greg:
> 
> This patch fix CVE-2023-0597[1],

The kernel developers do not care about CVEs as they are almost always
invalid and do not mean anything, sorry.  It is well known that
companies like Red Hat use them to make up for broken internal
engineering policies.

Are you sure this really is a valid problem that must be fixed in older
kernels?

> this CVE report a flaw possibility of memory leak. And this is
> important for some products using this stable version.

What exact memory leak are you referring to?

thanks,

greg k-h

Re: Consultation on backport 97e3d26b5e5f("x86/mm: Randomize per-cpu entry area") to stable

[Tong Tiangen]

在 2023/2/21 16:40, Greg KH 写道:
> On Tue, Feb 21, 2023 at 03:46:27PM +0800, Tong Tiangen wrote:
>>
>>
>> 在 2023/2/21 15:30, Greg KH 写道:
>>> On Tue, Feb 21, 2023 at 03:19:05PM +0800, Tong Tiangen wrote:
>>>> Hi peter:
>>>>
>>>> Do you have any plans to backport this patch[1] to the stable branch of the
>>>> lower version, such as 4.19.y ?
>>>
>>> Why?  That is a new feature for 6.2 why would it be needed to fix
>>> anything in really old kernels?
>>
>> Hi Greg:
>>
>> This patch fix CVE-2023-0597[1],
> 
> The kernel developers do not care about CVEs as they are almost always
> invalid and do not mean anything, 

Ok, thanks.


> sorry.  It is well known that, companies like Red Hat use them to make up 
> for broken internal engineering policies.

Yeah, For company's internal engineering policies, the CVE with certain 
impact must be repaired.

> 
> Are you sure this really is a valid problem that must be fixed in older
> kernels?
> 
>> this CVE report a flaw possibility of memory leak. And this is
>> important for some products using this stable version.
> 
> What exact memory leak are you referring to?

Sorry for Inaccurate description, the memory leak means: a potential 
security risk of kernel memory information disclosure caused by no 
randomization of the exception stacks.

> 
> thanks,
> 
> greg k-h
> .

Thanks,
Tong
.

Re: Consultation on backport 97e3d26b5e5f("x86/mm: Randomize per-cpu entry area") to stable

[Greg KH]

On Tue, Feb 21, 2023 at 05:19:42PM +0800, Tong Tiangen wrote:
> 
> 
> 在 2023/2/21 16:40, Greg KH 写道:
> > On Tue, Feb 21, 2023 at 03:46:27PM +0800, Tong Tiangen wrote:
> > > 
> > > 
> > > 在 2023/2/21 15:30, Greg KH 写道:
> > > > On Tue, Feb 21, 2023 at 03:19:05PM +0800, Tong Tiangen wrote:
> > > > > Hi peter:
> > > > > 
> > > > > Do you have any plans to backport this patch[1] to the stable branch of the
> > > > > lower version, such as 4.19.y ?
> > > > 
> > > > Why?  That is a new feature for 6.2 why would it be needed to fix
> > > > anything in really old kernels?
> > > 
> > > Hi Greg:
> > > 
> > > This patch fix CVE-2023-0597[1],
> > 
> > The kernel developers do not care about CVEs as they are almost always
> > invalid and do not mean anything,
> 
> Ok, thanks.
> 
> 
> > sorry.  It is well known that, companies like Red Hat use them to make
> > up for broken internal engineering policies.
> 
> Yeah, For company's internal engineering policies, the CVE with certain
> impact must be repaired.

So you are letting an opaque US government agency, and random third
party companies, dictate your company's internal engineering policies
and resource allocations?  That feels very very odd and ripe for abuse.

Also note that MITRE refuses to allocate CVEs for many real kernel
issues for unknown reasons, (i.e. they reject all of my requests), so
you are getting only a small subset of real issues here.

Also, how do you handle revocation of CVEs that are obviously invalid
and/or don't actually do anything (like this one?)

> > Are you sure this really is a valid problem that must be fixed in older
> > kernels?
> > 
> > > this CVE report a flaw possibility of memory leak. And this is
> > > important for some products using this stable version.
> > 
> > What exact memory leak are you referring to?
> 
> Sorry for Inaccurate description, the memory leak means: a potential
> security risk of kernel memory information disclosure caused by no
> randomization of the exception stacks.

And are you sure this can really happen?  Have you proven this?

And why is this really an issue, KASR is a known-week-defense and almost
useless against local attacks.

Anyway, please provide working patches if you think this really is an
issue.

And please revisit your company's policies, they do not seem very sane :)

thanks,

greg k-h

Re: Consultation on backport 97e3d26b5e5f("x86/mm: Randomize per-cpu entry area") to stable

[Tong Tiangen]

在 2023/2/21 18:40, Greg KH 写道:
> On Tue, Feb 21, 2023 at 05:19:42PM +0800, Tong Tiangen wrote:
>>
>>
>> 在 2023/2/21 16:40, Greg KH 写道:
>>> On Tue, Feb 21, 2023 at 03:46:27PM +0800, Tong Tiangen wrote:
>>>>
>>>>
>>>> 在 2023/2/21 15:30, Greg KH 写道:
>>>>> On Tue, Feb 21, 2023 at 03:19:05PM +0800, Tong Tiangen wrote:
>>>>>> Hi peter:
>>>>>>
>>>>>> Do you have any plans to backport this patch[1] to the stable branch of the
>>>>>> lower version, such as 4.19.y ?
>>>>>
>>>>> Why?  That is a new feature for 6.2 why would it be needed to fix
>>>>> anything in really old kernels?
>>>>
>>>> Hi Greg:
>>>>
>>>> This patch fix CVE-2023-0597[1],
>>>
>>> The kernel developers do not care about CVEs as they are almost always
>>> invalid and do not mean anything,
>>
>> Ok, thanks.
>>
>>
>>> sorry.  It is well known that, companies like Red Hat use them to make
>>> up for broken internal engineering policies.
>>
>> Yeah, For company's internal engineering policies, the CVE with certain
>> impact must be repaired.
> 
> So you are letting an opaque US government agency, and random third
> party companies, dictate your company's internal engineering policies
> and resource allocations?  That feels very very odd and ripe for abuse.
> 
> Also note that MITRE refuses to allocate CVEs for many real kernel
> issues for unknown reasons, (i.e. they reject all of my requests), so
> you are getting only a small subset of real issues here.
> 
> Also, how do you handle revocation of CVEs that are obviously invalid
> and/or don't actually do anything (like this one?)
> 
>>> Are you sure this really is a valid problem that must be fixed in older
>>> kernels?
>>>
>>>> this CVE report a flaw possibility of memory leak. And this is
>>>> important for some products using this stable version.
>>>
>>> What exact memory leak are you referring to?
>>
>> Sorry for Inaccurate description, the memory leak means: a potential
>> security risk of kernel memory information disclosure caused by no
>> randomization of the exception stacks.
> 
> And are you sure this can really happen?  Have you proven this?
> 
> And why is this really an issue, KASR is a known-week-defense and almost
> useless against local attacks.
> 
> Anyway, please provide working patches if you think this really is an
> issue.
> 
> And please revisit your company's policies, they do not seem very sane :)

Hi Greg:

Thanks for these very useful suggestions and we will revisit our policies :)

Thanks,
Tong
.

> 
> thanks,
> 
> greg k-h
> .

Re: Consultation on backport 97e3d26b5e5f("x86/mm: Randomize per-cpu entry area") to stable

[Tong Tiangen]

在 2023/2/22 4:26, Seth Jenkins 写道:
>  > So you are letting an opaque US government agency, and random third
>  > party companies, dictate your company's internal engineering policies
>  > and resource allocations?  That feels very very odd and ripe for abuse.
> I wholeheartedly agree with gregkh that the CVE system is flawed in 
> numerous ways and generates many false positives, however in this case, 
> this issue is a real issue with real security impact that received a 
> real patch upstream. The idea of backporting this to earlier kernels 
> probably warrants discussion if someone is willing to bite off that 
> work. But this gets into the fuzzy "backporting exploit mitigations to 
> stable" conversation.
> 
>  > And are you sure this can really happen?  Have you proven this?
> Yes this can really, provably, happen:
> https://googleprojectzero.blogspot.com/2022/12/exploiting-CVE-2022-42703-bringing-back-the-stack-attack.html 
> <https://googleprojectzero.blogspot.com/2022/12/exploiting-CVE-2022-42703-bringing-back-the-stack-attack.html>
> 
>  > And why is this really an issue, KAS[L]R is a known-weak-defense and 
> almost
>  > useless against local attacks.
> Granted, Peter Z's fix does help to mitigate the impact from remote 
> attackers but yes this fix does not resolve the security impact from 
> local exploits.

Thank you seth.
Yes, for this specific CVE issue, KASLR is indeed a mitigation measure.

> 
> 
> On Tue, Feb 21, 2023 at 7:30 AM Tong Tiangen <tongtiangen@huawei.com 
> <mailto:tongtiangen@huawei.com>> wrote:
> 
> 
> 
>     在 2023/2/21 18:40, Greg KH 写道:
>      > On Tue, Feb 21, 2023 at 05:19:42PM +0800, Tong Tiangen wrote:
>      >>
>      >>
>      >> 在 2023/2/21 16:40, Greg KH 写道:
>      >>> On Tue, Feb 21, 2023 at 03:46:27PM +0800, Tong Tiangen wrote:
>      >>>>
>      >>>>
>      >>>> 在 2023/2/21 15:30, Greg KH 写道:
>      >>>>> On Tue, Feb 21, 2023 at 03:19:05PM +0800, Tong Tiangen wrote:
>      >>>>>> Hi peter:
>      >>>>>>
>      >>>>>> Do you have any plans to backport this patch[1] to the
>     stable branch of the
>      >>>>>> lower version, such as 4.19.y ?
>      >>>>>
>      >>>>> Why?  That is a new feature for 6.2 why would it be needed to fix
>      >>>>> anything in really old kernels?
>      >>>>
>      >>>> Hi Greg:
>      >>>>
>      >>>> This patch fix CVE-2023-0597[1],
>      >>>
>      >>> The kernel developers do not care about CVEs as they are almost
>     always
>      >>> invalid and do not mean anything,
>      >>
>      >> Ok, thanks.
>      >>
>      >>
>      >>> sorry.  It is well known that, companies like Red Hat use them
>     to make
>      >>> up for broken internal engineering policies.
>      >>
>      >> Yeah, For company's internal engineering policies, the CVE with
>     certain
>      >> impact must be repaired.
>      >
>      > So you are letting an opaque US government agency, and random third
>      > party companies, dictate your company's internal engineering policies
>      > and resource allocations?  That feels very very odd and ripe for
>     abuse.
>      >
>      > Also note that MITRE refuses to allocate CVEs for many real kernel
>      > issues for unknown reasons, (i.e. they reject all of my requests), so
>      > you are getting only a small subset of real issues here.
>      >
>      > Also, how do you handle revocation of CVEs that are obviously invalid
>      > and/or don't actually do anything (like this one?)
>      >
>      >>> Are you sure this really is a valid problem that must be fixed
>     in older
>      >>> kernels?
>      >>>
>      >>>> this CVE report a flaw possibility of memory leak. And this is
>      >>>> important for some products using this stable version.
>      >>>
>      >>> What exact memory leak are you referring to?
>      >>
>      >> Sorry for Inaccurate description, the memory leak means: a potential
>      >> security risk of kernel memory information disclosure caused by no
>      >> randomization of the exception stacks.
>      >
>      > And are you sure this can really happen?  Have you proven this?
>      >
>      > And why is this really an issue, KASR is a known-week-defense and
>     almost
>      > useless against local attacks.
>      >
>      > Anyway, please provide working patches if you think this really is an
>      > issue.
>      >
>      > And please revisit your company's policies, they do not seem very
>     sane :)
> 
>     Hi Greg:
> 
>     Thanks for these very useful suggestions and we will revisit our
>     policies :)
> 
>     Thanks,
>     Tong
>     .
> 
>      >
>      > thanks,
>      >
>      > greg k-h
>      > .
>