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.
> 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?
> 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/
So maybe work to see if this is a real problem or not first, before
worrying about backporting it?
thanks,
greg k-h
