lkml.org 
[lkml]   [2024]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v3] Documentation: Document the Linux Kernel CVE process
    On Fri, Feb 16, 2024 at 02:20:04PM +0100, Michal Hocko wrote:
    > > Right now
    > > we are fixing lots and lots of things and no one notices as their
    > > "traditional" path of only looking at CVEs for the kernel is totally
    > > incorrect.
    >
    > Right, there are quite a lot of people who consider CVE fixes much more
    > important than regular fixes. Their reasoning might be completely
    > misleading but there might be very good reasons to stick to minimalistic
    > approach, e.g. to reduce risk of regressions.
    >
    > I believe it is perfectly fair to say that whoever relies on stable
    > kernels support needs to update to the latest stable kernel version to
    > be covered by security and functional fixes. On the other hand I do not
    > think it is an improvement to the process to swamp CVE database with any
    > random fixes without a proper evaluation. If the kernel community
    > doesn't believe in the CVE process then fair enough, just do not assign
    > them unless you want to explicitly call out fixes with a high impact
    > security implications. Having fewer good quality CVEs would definitely
    > improve the process.

    As you know, it's almost impossible to determine if a fix is "high
    impact" or not, given that we have no idea what anyone's use case is for
    the kernel. We have documented proof of single-byte-buffer-overflows
    resulting in complete system takeovers, and the same for very tiny
    use-after-free issues, and the same for tiny "overflow a USB string
    buffer" issues, and so on.

    So as always, we need to treat "a bug is a bug is a bug" and when
    looking at the bug fix, if it resolves something that is known to be
    a vulnerability (again, as defined by CVE themselves), then we need to
    mark it as such.

    If you find that we are marking things as a CVE thatt you do not feel
    should be marked as such, please let us know and we will be glad to
    discuss it on a case-by-case basis.

    But note, this type of classification has been happening for the kernel
    stable commits for 2+ years now, by Sasha, in the GSD records, so this
    isn't something new that we have been doing, it's just that only a very
    small group were noticing that, and now a larger one might notice this.

    thanks,

    greg k-h

    \
     
     \ /
      Last update: 2024-05-27 15:06    [W:4.183 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site