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
On Mon, Jun 03, 2019 at 10:31:15AM -0700, Zubin Mithra wrote:
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()")
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...
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
On Tue, Jun 04, 2019 at 09:52:35AM +0200, Greg KH wrote:
On Mon, Jun 03, 2019 at 10:31:15AM -0700, Zubin Mithra wrote:
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()")
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...
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
On Tue, Jun 4, 2019 at 12:52 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Jun 03, 2019 at 10:31:15AM -0700, Zubin Mithra wrote:
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()")
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.
That's something that can not be triggered by normal operations, right? It's a bugfix-for-the-theoritical from what I can see...
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
thanks,
greg k-h
On Tue, Jun 04, 2019 at 01:43:17AM -0700, Guenter Roeck wrote:
On Tue, Jun 4, 2019 at 12:52 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Jun 03, 2019 at 10:31:15AM -0700, Zubin Mithra wrote:
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()")
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.
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.
That's something that can not be triggered by normal operations, right? It's a bugfix-for-the-theoritical from what I can see...
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
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Guenter Roeck -
Zubin Mithra