On Wed, Apr 26, 2023 at 11:44:30AM +0200, Kristof Havasi wrote:
> On Tue, 25 Apr 2023 at 20:08, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Tue, Apr 25, 2023 at 06:27:24PM +0200, Kristof Havasi wrote:
> > > On Tue, 25 Apr 2023 at 16:47, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > > >
> > > > On Tue, Apr 25, 2023 at 04:08:30PM +0200, Kristof Havasi wrote:
> > > > > Hi there,
> > > > >
> > > > > I was evaluating CVE-2022-3567 and CVE-2022-3566 which both
> > > > > revolt around load tearing and reference an ancient Kernel commit:
> > > > > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > > >
> > > > > I am not sure whether they are applicable to the v5.4.y branch as well.
> > > >
> > > > I do not know, what specific commits are you referring to? CVEs mean
> > > > nothing, they are not valid identifiers, sorry.
> > > >
> > > > And have you tried applying them to the older kernels and testing to see
> > > > if they solve any specific issue?
> > > >
> > > > Or better yet, why use the older kernels, why not stick to the most
> > > > recent one? What is preventing you from switching?
> > >
> > > Thank you for the quick response!
> > >
> > > I meant the following commits:
> > > f49cd2f4d6170d27a2c61f1fecb03d8a70c91f57 and
> > > 364f997b5cfe1db0d63a390fe7c801fa2b3115f6
> > >
> > > The v5.4 kernel is used in an embedded device where due to certification
> > > processes a quick upgrade of the Kernel isn't realistic until at least
> > > another year.
> >
> > You do realize that stable kernel updates can radically change the whole
> > system (look at the changes needed for retbleed), so any update needs to
> > always be properly tested. Version numbers mean nothing, so even if we
> > do take these patches, you still need to do proper testing, the same
> > amount of testing you would have done for moving to a new kernel
> > version.
>
> Yes, we are working on extending the tests, that is also how I found a
> regression
> candidate on the v5.4 LTS branch:
> https://lore.kernel.org/lkml/1473b364-777a-ede8-3ff6-36d9e1d577ad@xxxxxxxxxxxxx/
>
> >
> > > The patches are quite small, I could cherry-pick them on the latest v5.4 tag,
> > > and the kernel builds... only for
> > > f49cd2f4d6170d27a2c61f1fecb03d8a70c91f57 USER_SOCKPTR
> > > isn't available in 5.4, so I sticked to `char __user *`.
> >
> > Note that you also need to provide backports for 5.15.y and 5.10.y as
> > you do not want to upgrade to a new version and have a regression,
> > right?
>
> Thank you, I didn't know that. Sorry for that, I am still just getting familiar
> with the Kernel development process and tooling.
Also, try sending emails for the individual patches, AND cc: the
developers and subsystems involved to get their opinions. To not do so
is wasteful as the developers know the change best, right?
> > > I will get a device tomorrow and try whether I can netcat between them
> > > via IPv4 and v6.
> > > Any other tests, which would be needed?
> >
> > Why does the existance of a random CVE number mean anything? You do
> > know that MITRE (the entity that deals out CVEs), refuses to give the
> > kernel team new CVE numbers for bug reports, right? So that means that
> > any kernel-related CVE that you see are created by vendors who are using
> > them to facilitate their internal engineering processes, not necessarily
> > anything else.
> >
> > I gave a whole long talk about this a few years ago if you are
> > interested:
> > https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/
> >
>
> OMG, thanks for the link, you summed up quite the frustration of mine from
> the past days, since I had to go through 500+ CVEs and classify them,
> whether they "affect" 5.4.238... The whole "versioning" and references
> are so lacking. But common criteria evaluations want to see all CVEs
> classified... (Don't want to start another rant on CC...)
Why are you all saying that CVEs are even a valid thing for the kernel
at all? Please don't.
> But if we forget the whole CVE thing for a moment, if there is a commit,
> in the mainline which references a 2.6 kernel commit via "Fixes",
> but this commit isn't picked into the LTS streams, how should I proceed?
> (Not relevant or slipped through the creeks?)
A "bare" Fixes: tag never means that the change needs to be backported
to stable kernels, as per our documentation, you need to add a cc:
stable to the patch as well to guarantee it.
That being said, we do sweep the tree at times and pick up obvious
things that have Fixes only, and try to apply them, but do so at a "best
case" basis.
For these specific patches, they just do not apply to older kernels at
all, so of course they will not be added to older kernels. If you think
they do need to be applied, please rework them and submit them to us and
we will be glad to review them (and cc: the relevant developers as
well.)
So that's why they were not backported further than where they are now,
no one took the time to do the work.
Also, are these actually real issues for you? Dealing with smp tearing
issues like this is good to fix, but can you hit them in your device and
are they relevant for your processor? (yet another reason why CVEs for
the kernel are bunk, hardware is never taken into consideration...)
> > So maybe work to see if this is a real problem or not first, before
> > worrying about backporting it?
>
> Seeing the commit merged into the mainline tree and that it looked rather
> reasonable to do the ref-counting, made the impression to me that it is
> a valid patch.
They are valid changes for the kernels they were written for. Now if
they are relevant for older kernels or not is unknown. How about asking
the vendor who created those CVEs? They would know why they created the
entries, even if it was to handle their internal engineering
processes...
Hope this helps,
greg k-h
