95baa60a0da8 ("ipv6_sockglue: Fix a missing-check bug in ip6_ra_control()")
Hello,
CVE-2019-12378 was fixed in the upstream linux kernel with the following commit.
* 95baa60a0da8 ("ipv6_sockglue: Fix a missing-check bug in ip6_ra_control()")
Could the patch be applied to v4.19.y, v4.14.y, v4.9.y and v4.4.y?
Tests run:
* Chrome OS tryjobs
Thanks,
- Zubin
Greg KH
maintainerQuoted 4 lines · Zubin Mithra
Hello,
CVE-2019-12378 was fixed in the upstream linux kernel with the following commit.
*95baa60a0da8("ipv6_sockglue: Fix a missing-check bug inip6_ra_control()")
A CVE was created for that tiny thing?
Hah, no, I think I'll refuse to apply it just for the very point of it. That's something that can not be triggered by normal operations, right? It's a bugfix-for-the-theoritical from what I can see...
Quoted 1 line
Could the patch be applied to v4.19.y, v4.14.y, v4.9.y and v4.4.y?
Why are you ignoring 5.1?
thanks,
greg k-h
Greg KH
maintainerQuoted 8 lines · Greg KH
Quoted 4 lines · Zubin Mithra
Hello,
CVE-2019-12378 was fixed in the upstream linux kernel with the following commit.
*95baa60a0da8("ipv6_sockglue: Fix a missing-check bug inip6_ra_control()")A CVE was created for that tiny thing?
Quoted 7 lines
Hah, no, I think I'll refuse to apply it just for the very point of it. That's something that can not be triggered by normal operations, right? It's a bugfix-for-the-theoritical from what I can see...
Quoted 1 line
Could the patch be applied to v4.19.y, v4.14.y, v4.9.y and v4.4.y?
Why are you ignoring 5.1?
Also, stable networking patches need to come from the networking maintainer, as the documentation states, so I shouldn't be applying this directly anyway. If Dave thinks it is worth to backport, I'll gladly apply it from his submissions, so you need to convince him, not me.
thanks,
greg k-h
Quoted 10 lines · Greg KH
Quoted 4 lines · Zubin Mithra
Hello,
CVE-2019-12378 was fixed in the upstream linux kernel with the following commit.
*95baa60a0da8("ipv6_sockglue: Fix a missing-check bug inip6_ra_control()")A CVE was created for that tiny thing?
Hah, no, I think I'll refuse to apply it just for the very point of it.
We don't create CVEs, but we do have to get CVE fixes applied to our branches. We don't try to police the creation of CVEs, and we don't try to double-guess them since that would be futile (who guarantees that our double-guessing matches yours ?). We do have a policy to not apply CVEs directly but ask for stable tree merges instead to avoid deviation, and we (more specifically, Zubin) spend a lot of time validating the fixes before sending a request. I just made that official policy, but a policy is not cast in stone. We will stop doing that if we get this kind of response. If that is what you want, let me know.
Zubin, maybe hold back with -stable backport requests for the time being, and just apply missing patches directly to our branches. Sorry for the trouble.
Quoted 7 lines
That's something that can not be triggered by normal operations, right? It's a bugfix-for-the-theoritical from what I can see...
Quoted 1 line
Could the patch be applied to v4.19.y, v4.14.y, v4.9.y and v4.4.y?
Why are you ignoring 5.1?
Probably because no one is perfect.
Thanks,
Guenter
Quoted 3 lines
thanks,
greg k-h
Greg KH
maintainerQuoted 23 lines · Guenter Roeck
Quoted 10 lines · Greg KH
Quoted 4 lines · Zubin Mithra
Hello,
CVE-2019-12378 was fixed in the upstream linux kernel with the following commit.
*95baa60a0da8("ipv6_sockglue: Fix a missing-check bug inip6_ra_control()")A CVE was created for that tiny thing?
Hah, no, I think I'll refuse to apply it just for the very point of it.
We don't create CVEs, but we do have to get CVE fixes applied to our branches. We don't try to police the creation of CVEs, and we don't try to double-guess them since that would be futile (who guarantees that our double-guessing matches yours ?). We do have a policy to not apply CVEs directly but ask for stable tree merges instead to avoid deviation, and we (more specifically, Zubin) spend a lot of time validating the fixes before sending a request. I just made that official policy, but a policy is not cast in stone. We will stop doing that if we get this kind of response. If that is what you want, let me know.
Quoted 3 lines
Zubin, maybe hold back with -stable backport requests for the time being, and just apply missing patches directly to our branches. Sorry for the trouble.
It's not "trouble", and don't hold back on requesting stable backports, I'm not asking for that at all, be reasonable.
What I am asking for is pushing back on the "all CVEs must be applied" when obviously the patch is dumb. It is trivial for anyone to get a CVE for a kernel patch these days, and loads of work to try to get one revoked (I tried in the past, gave up due to it being futile.)
So while CVEs might be a "flag" that you should look at something, they are never a "this MUST be applied" rule that ANYONE should ever follow.
Quoted 8 lines
Quoted 7 lines
That's something that can not be triggered by normal operations, right? It's a bugfix-for-the-theoritical from what I can see...
Quoted 1 line
Could the patch be applied to v4.19.y, v4.14.y, v4.9.y and v4.4.y?
Why are you ignoring 5.1?
Probably because no one is perfect.
That's fine, but always remember that I can not apply patches only to older stable kernels and not newer ones. When you see a patch is only in 5.2-rcX, that's a big hint that maybe it should go to all stable releases, if necessary.
And again, as always, for networking stable patches, please follow the documented rules for how to ask for them.
thanks,
greg k-h