[back to public] [original thread [PATCH Backport to stable/linux-4.14.y] make 'user_access_begin()' do 'access_ok()']
On Thu, Apr 02, 2020 at 09:00:14AM +0000, Schmid, Carsten wrote:
Well, your view, and i completely understand your POV.
Mine is (i don't have such a pretty recording of a discussion, so some
words):
- A "CVE" describes a vulnerability found in some product in some version. Nothing else. It's kind of a "vulnerability identifier".
- The information collected around the CVE tries to explain (i intentionally
write "tries")
which countermeasures could be taken to mitigate. The quality is sometimes good, sometimes not - that really bothers.
- And finally, a "CVE fix" is nothing else than a collection of changes to the
product to be done.
This can be even different for the same vulnerability on different
products.
It's not only a commit id, nor only one CID. Its most times a collection of
them.
I totally agree: "A bug is a bug is a bug" (and not always a feature like some people say ;-) )
In Linux kernel context:
- The best way to mitigate is to use latest and greatest - or latest LTS.
Whatever fits.
I totally agree.
- In case i am a developer who is told by the customer and the chip vendor:
then things are quite different.
- We have a vendor kernel
- We follow upstream LTS
- We have millions of devices in the field with dedicated setup
- Updates need to be tested carefully for our products
- We only have a subset of the kernel functions active
- There is a delay in between the LTS going into vendor kernel (10-20
weeks or so)
(They say they need this time for testing)
- There is a delay until integration into the product and updates are tested (This time could also be 10+ weeks)
- There are vulnerabilities that temporary can be fixed by cherry-picking (until the next LTS "round" from the vendor kernel arrives)
- CVE descriptions of NVD and other sources give at least an impression if it makes sense to try a temporary backport
I will be glad to discuss this and point out where something can be fixed, if you want to talk about it in public, as remember, you are not the only one in this situation.
greg k-h
Of course, thanks. And as this is something in networking i add the netdev folks also.
There is one CVE report that affects our project, and is not yet fixed in LTS (current 4.14.174). It is a leak that data is sent unencrypted - and this really is an issue for us: From https://access.redhat.com/security/cve/cve-2020-1749 A flaw was found in the Linux kernel's implementation of some networking protocols in IPsec, such as VXLAN and GENEVE tunnels over IPv6. When an encrypted tunnel is created between two hosts, the kernel isn't correctly routing tunneled data over the encrypted link; rather sending the data unencrypted. This would allow anyone in between the two endpoints to read the traffic unencrypted. The main threat from this vulnerability is to data confidentiality.
I have backported 3 fixes from v5.x to 4.14.147 (our current delivery from vendor), see attached patch files. Mentioned in https://security-tracker.debian.org/tracker/CVE-2020-1749 the patch https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... is given as a fix, but only this one is hard to port, so i added 2 more.
From my understanding, in 4.14 the vulnerability exists. (i did not check yet if it's also an issue in other LTS kernels - but i assume at least in 4.19 it is)
I would be glad to hear your opinion on that. If you find it worth, i would backport to stable/linux-4.14.y (and maybe 4.19.y too, but i think there is a different patch set needed) and send upstream.
Best regards Carsten ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter