On Tue, Apr 25, 2023 at 06:27:24PM +0200, Kristof Havasi wrote:
On Tue, 25 Apr 2023 at 16:47, Greg KH gregkh@linuxfoundation.org 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