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

[Tong Tiangen <tongtiangen@huawei.com>]

在 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
> .