On 14/09/2015 20:59, Stefan Geißler wrote: >> >> There could be many reasons. For example the problem could be very >> minor, the patches could have problems, or a second patch was needed >> because the first fix was insufficient so. It's difficult to say >> without seeing the CVE and patch for the 183-day record. > > The delay belongs to CVE-2013-4587. According to NVD the patch (a git > commit) was submitted on 2013-12-12 while the CVE number was assigned on > 2013-06-12. > > But since i have some cases in my dataset that show similar (~80% of > identified vulnerabilities are fixed within 100 days) behaviour i am > more interested in the general info you already provided. Actually there is a fourth reason: the CVE was not made public, not even to other organization than the discoverer, for a long time. My data is that the CVE was assigned on 2013-06-12 but it was reported to the maintainers only on 2013-11-15. It took 27 days from 2013-11-15 to the release of the fix. Until the date of the report, what happened within the organization is effectively impossible to know. Most likely some kind of internal process failure. You can often go to a URL like https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-4587 to see the date that the CVE was reported, since Red Hat creates meta-bugs for CVEs in their products. Other Linux distros probably have something similar. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
