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.
>
> > 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...)
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?)
> 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.
Thanks again for the talk and the replies, helps a lot to see how the LTS
is maintained.
Best Regards,
Kristóf
