Message ID | 2024021430-blanching-spotter-c7c8@gregkh |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-64852-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:bc8a:b0:106:860b:bbdd with SMTP id dn10csp1055991dyb; Wed, 14 Feb 2024 00:02:04 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCX6l3pfMCeS2OiPIVzw1RLTf+dWJnst4t9rtHwyWLOciictAjVCpYUaNL8m+8e1FowKGfW7CvHcNj8HCTYqcAWlz4+slA== X-Google-Smtp-Source: AGHT+IGCmUjY3BA9noZDjGfAEGI79ub3kn0tC/VIyvdlYdRH0/iMPa7yrEGK6P8BrNbat1u8BzKH X-Received: by 2002:a05:6870:3312:b0:219:7915:e995 with SMTP id x18-20020a056870331200b002197915e995mr1907644oae.19.1707897724458; Wed, 14 Feb 2024 00:02:04 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707897724; cv=pass; d=google.com; s=arc-20160816; b=PNDxlWodZH7fTraSoGqKg0EqxPh2EesMeTFFbQZx4ZvQsXICpaOGlqpMDh0MrC4Mi+ fn3yH9qz/51LVekOupx7gHBwoxxNQHaTTr5xqsbjJRaHoqtKK0aRZdL1Uz9LG6ZO+Fer HhIhcwypv4TCtKCNPaS9Oa3YUhrdQR81309C2fMgeHsz968tXspsZcwBXN+F5miYjujp od4VxIASjDLksj0OazKlYl8/qxyQqqGc0XNbPVwjWnhFHyn/TACQiZS33RdgvV5Ce658 FE8C5hnqnQTFLacqzFswiJU5qeSfNCP/CGat42OiLNa8t2FQ3WMdFozL8rkzv2wlxKMS K5+Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:lines:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=rTxRH3wmnnoqP5WpiEIplEtDSxhLN+T9WMI4UaKSxsU=; fh=eru68CqPqqR2ViGcxGQPqMDpA7ovdOYA4x+NRq56NkU=; b=oemwRZx0Xn+AK+t8kCoOGSJ4GkZG++Y+Um0/ivdedF+gWB9Fa1Bnk0EmO7TWyo1prW zOY6aE47o088uWItUigUctnbFhzn2QaCAahJ722/NwDu9211YxDN+ebVXyFCKCW6tNTR uLqwrkIQL+QqxLhlOP+5I25DGRX6JWy7XB9O9cS01H1nzK7lRJ1VgjiZfCgYT4eenroi 2HuDXYmegMXOgFUNNvk5SH5apjf+04Z1NR62AOHr6j3cvEshIFIopJHIbdZigxx6YMOP QHuF0k3gVJI0msb0bM4Yr5039gFmrNUUftdzkS1e/5G8HXl2XkJihjX/NPoNlVsp3C4F 67FA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="XGOvXL/8"; arc=pass (i=1 dkim=pass dkdomain=linuxfoundation.org); spf=pass (google.com: domain of linux-kernel+bounces-64852-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-64852-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org X-Forwarded-Encrypted: i=2; AJvYcCXAMIJBt6ognMFGxabvl90e3m7qtdTEf2njx7eg0uV7ak6NJkUQraBC3OPbyw4We9IJh3QSoym7QXHnMn/HcLK05WMJvg== Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id vu9-20020a05620a560900b007835218c6f3si9839942qkn.230.2024.02.14.00.02.04 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Feb 2024 00:02:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-64852-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="XGOvXL/8"; arc=pass (i=1 dkim=pass dkdomain=linuxfoundation.org); spf=pass (google.com: domain of linux-kernel+bounces-64852-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-64852-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 0A18C1C2724C for <ouuuleilei@gmail.com>; Wed, 14 Feb 2024 08:01:20 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3BD7012E73; Wed, 14 Feb 2024 08:00:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="XGOvXL/8" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A01CF12E43; Wed, 14 Feb 2024 08:00:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707897639; cv=none; b=t92wYzKppPbNOgympaA8QMu2Bu6JyEk8PEbADrYhAKg5GLzE11ndeM8PvhISH/Vo1H28pLJ0E6L7hhYU2muUCMhbCZx0qcs9Zu6BphRxzDlRyDW07Xagw0t7jtYiFrHYcUWS1goWthP2twPYNyXupLw9s+6M/4sBrHPKxYRSW0M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707897639; c=relaxed/simple; bh=FmvLaKNhnIFQSuhbWRcDujMa+s+t+I+o5kK0EywbO78=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=gLGygs031uok+IpN9jCiHsRpqHjUKOef8lk+LktU9qyCfFEj1GHLFnXpdDK7uY9BLtJQf3gytc11KGiB6otl3TSGK3JpMvFxiFUeVO3UlPzrofRKNjXSLZekbqPKknELDiSBnBZeMaMk59Jhcspju/MjJf/nNFrszyT8ahe+JDk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=XGOvXL/8; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F5ECC43394; Wed, 14 Feb 2024 08:00:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1707897639; bh=FmvLaKNhnIFQSuhbWRcDujMa+s+t+I+o5kK0EywbO78=; h=From:To:Cc:Subject:Date:From; b=XGOvXL/8iOjG1X58cQE/qDUHLGF/1cHQjE1e3f4SAdQWodf1imzAnGjl/c8XqFmGM PpuuwwcsvjQr5uTYtmtR/2DWsLdNYSVyifU0EhHOpZsYM4g+QRnJ3VHG3PrgmfmeQw BZsouhEhW13Nf15KhFQpwwgWw7phgcFc+MB57FPE= From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> To: corbet@lwn.net, workflows@vger.kernel.org Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, security@kernel.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Kees Cook <keescook@chromium.org>, Sasha Levin <sashal@kernel.org>, Lee Jones <lee@kernel.org> Subject: [PATCH v3] Documentation: Document the Linux Kernel CVE process Date: Wed, 14 Feb 2024 09:00:30 +0100 Message-ID: <2024021430-blanching-spotter-c7c8@gregkh> X-Mailer: git-send-email 2.43.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Lines: 179 X-Developer-Signature: v=1; a=openpgp-sha256; l=8803; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=FmvLaKNhnIFQSuhbWRcDujMa+s+t+I+o5kK0EywbO78=; b=owGbwMvMwCRo6H6F97bub03G02pJDKlniuW2uSR9PGwa03xOXG7K1qUxjvMT2xYYpL88s3nnz un5vYItHbEsDIJMDLJiiixftvEc3V9xSNHL0PY0zBxWJpAhDFycAjCRxdYM82Py9FNuPq9fkNzw /OvZHy+OuuiHaDAsWPfkurjtYZNDs0/lSYu7/VS8bRHRDwA= X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790810842447927624 X-GMAIL-MSGID: 1790860564539439490 |
Series |
[v3] Documentation: Document the Linux Kernel CVE process
|
|
Commit Message
Greg KH
Feb. 14, 2024, 8 a.m. UTC
The Linux kernel project now has the ability to assign CVEs to fixed issues, so document the process and how individual developers can get a CVE if one is not automatically assigned for their fixes. Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Lee Jones <lee@kernel.org> --- v3: fix up wording in security-bugs.rst based on the changes to the cve assignment process from v1, thanks to a private reviewer for pointing that out. v2: Grammer fixes based on review from Randy Updated paragraph about how CVE identifiers will be assigned (automatically when added to stable trees, or ask us for one directly before that happens if so desired) Documentation/process/cve.rst | 120 ++++++++++++++++++++++++ Documentation/process/index.rst | 1 + Documentation/process/security-bugs.rst | 5 +- 3 files changed, 123 insertions(+), 3 deletions(-) create mode 100644 Documentation/process/cve.rst
Comments
On Wed, Feb 14, 2024 at 9:01 AM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > The Linux kernel project now has the ability to assign CVEs to fixed > issues, so document the process and how individual developers can get a > CVE if one is not automatically assigned for their fixes. > > Reviewed-by: Kees Cook <keescook@chromium.org> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Signed-off-by: Sasha Levin <sashal@kernel.org> > Signed-off-by: Lee Jones <lee@kernel.org> > --- > v3: fix up wording in security-bugs.rst based on the changes to the cve > assignment process from v1, thanks to a private reviewer for > pointing that out. > v2: Grammer fixes based on review from Randy > Updated paragraph about how CVE identifiers will be assigned > (automatically when added to stable trees, or ask us for one > directly before that happens if so desired) > Hi Greg, Sasha, Lee, Generally, I think this is a great step forward on the whole "security vulnerability mess" and this will certainly help me and others in the embedded space to argue to update to recent stable kernel versions. This can then finally put the practice of shipping multiple-year-old kernel versions to an end. Often this was just done with the argument that there is not a recent CVE and fix assigned to some recent stable kernel version---and integrators think updates to recent kernel stable versions are not needed and not recommended. I am looking forward to seeing what and how many stable commits are going to get CVEs assigned. If Greg's policy from the Kernel Recipes 2019 presentation comes into play, every git kernel hash (GKH)---at least in the stable tree---could get a CVE identifier (just to be on the safe side). But I assume you are going to use some expert knowledge, heuristics or some machine-learning AI to make some commits in the stable tree carrying a CVE identifier and some others not. Reviewed-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Below, there is just some nitpicking on some wording: > Documentation/process/cve.rst | 120 ++++++++++++++++++++++++ > Documentation/process/index.rst | 1 + > Documentation/process/security-bugs.rst | 5 +- > 3 files changed, 123 insertions(+), 3 deletions(-) > create mode 100644 Documentation/process/cve.rst > > diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst > new file mode 100644 > index 000000000000..6465e6a79c18 > --- /dev/null > +++ b/Documentation/process/cve.rst > @@ -0,0 +1,120 @@ > +CVEs > +==== > + > +Common Vulnerabilities and Exposure (CVE®) numbers were developed as an > +unambiguous way to identify, define, and catalog publicly disclosed > +security vulnerabilities. Over time, their usefulness has declined with > +regards to the kernel project, and CVE numbers were very often assigned > +in inappropriate ways and for inappropriate reasons. Because of this, > +the kernel development community has tended to avoid them. However, the > +combination of continuing pressure to assign CVEs and other forms of > +security identifiers, and ongoing abuses by community members outside of > +the kernel community has made it clear that the kernel community should > +have control over those assignments. > + Though, I get what is meant with "the community members outside of the kernel community", it still feels strange when reading. Here are some alternatives I could come up with: "reporters outside the kernel community" "reporters beyond the actively contributing/engaged kernel community members" "individuals not engaged with the kernel community" > +The Linux kernel developer team does have the ability to assign CVEs for > +potential Linux kernel security issues. This assignment is independent > +of the :doc:`normal Linux kernel security bug reporting > +process<../process/security_bugs>`. > + > +A list of all assigned CVEs for the Linux kernel can be found in the > +archives of the linux-cve mailing list, as seen on > +https://lore.kernel.org/linux-cve-announce/. To get notice of the > +assigned CVEs, please subscribe to that mailing list. > + > +Process > +------- > + > +As part of the normal stable release process, kernel changes that are > +potentially security issues are identified by the developers responsible > +for CVE number assignments and have CVE numbers automatically assigned > +to them. These assignments are published on the linux-cve-announce > +mailing list as announcements on a frequent basis. > + > +Note, due to the layer at which the Linux kernel is in a system, almost > +any bug might be exploitable to compromise the security of the kernel, Just a nit: but I would say: a kernel bug is compromising the "security of the system"; the kernel bug just happens to allow anyone to run any code on their hardware... in some systems that is a security issue, but in my previous MSDOS system that was the default behaviour ;) > +but the possibility of exploitation is often not evident when the bug is > +fixed. Because of this, the CVE assignment team is overly cautious and > +assign CVE numbers to any bugfix that they identify. This > +explains the seemingly large number of CVEs that are issued by the Linux > +kernel team. > + > +If the CVE assignment team misses a specific fix that any user feels > +should have a CVE assigned to it, please email them at <cve@kernel.org> > +and the team there will work with you on it. Note that no potential > +security issues should be sent to this alias, it is ONLY for assignment > +of CVEs for fixes that are already in released kernel trees. If you > +feel you have found an unfixed security issue, please follow the > +:doc:`normal Linux kernel security bug reporting > +process<../process/security_bugs>`. > + > +No CVEs will be automatically assigned for unfixed security issues in > +the Linux kernel; assignment will only automatically happen after a fix > +is available and applied to a stable kernel tree, and it will be tracked > +that way by the git commit id of the original fix. If anyone wishes to > +have a CVE assigned before an issue is resolved with a commit, please > +contact the kernel CVE assignment team at <cve@kernel.org> to get an > +identifier assigned from their batch of reserved identifiers. > + > +No CVEs will be assigned for any issue found in a version of the kernel > +that is not currently being actively supported by the Stable/LTS kernel > +team. A list of the currently supported kernel branches can be found at > +https://kernel.org/category/releases.html > + > +Disputes of assigned CVEs > +------------------------- > + > +The authority to dispute or modify an assigned CVE for a specific kernel > +change lies solely with the maintainers of the relevant subsystem > +affected. This principle ensures a high degree of accuracy and > +accountability in vulnerability reporting. Only those individuals with > +deep expertise and intimate knowledge of the subsystem can effectively > +assess the validity and scope of a reported vulnerability and determine > +its appropriate CVE designation. Any attempt to modify or dispute a CVE > +outside of this designated authority could lead to confusion, inaccurate > +reporting, and ultimately, compromised systems. > + > +Invalid CVEs > +------------ > + > +If a security issue is found in a Linux kernel that is only supported by > +a Linux distribution due to the changes that have been made by that > +distribution, or due to the distribution supporting a kernel version > +that is no longer one of the kernel.org supported releases, then a CVE > +can not be assigned by the Linux kernel CVE team, and must be asked for > +from that Linux distribution itself. > + > +Any CVE that is assigned against the Linux kernel for an actively > +supported kernel version, by any group other than the kernel assignment > +CVE team should not be treated as a valid CVE. Please notify the > +kernel CVE assignment team at <cve@kernel.org> so that they can work to > +invalidate such entries through the CNA remediation process. > + > +Applicability of specific CVEs > +------------------------------ > + > +As the Linux kernel can be used in many different ways, with many > +different ways of accessing it by external users, or no access at all, > +the applicability of any specific CVE is up to the user of Linux to > +determine, it is not up to the CVE assignment team. Please do not > +contact us to attempt to determine the applicability of any specific > +CVE. > + > +Also, as the source tree is so large, and any one system only uses a > +small subset of the source tree, any users of Linux should be aware that > +large numbers of assigned CVEs are not relevant for their systems. > + > +In short, we do not know your use case, and we do not know what portions > +of the kernel that you use, so there is no way for us to determine if a > +specific CVE is relevant for your system. > + > +As always, it is best to take all released kernel changes, as they are > +tested together in a unified whole by many community members, and not as > +individual cherry-picked changes. Also note that for many bugs, the > +solution to the overall problem is not found in a single change, but by > +the sum of many fixes on top of each other. Ideally CVEs will be > +assigned to all fixes for all issues, but sometimes we do not notice > +fixes in released kernels, so do not assume that because a specific > +change does not have a CVE assigned to it, that it is not relevant to > +take. > + > diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst > index 6cb732dfcc72..de9cbb7bd7eb 100644 > --- a/Documentation/process/index.rst > +++ b/Documentation/process/index.rst > @@ -81,6 +81,7 @@ of special classes of bugs: regressions and security problems. > > handling-regressions > security-bugs > + cve > embargoed-hardware-issues > > Maintainer information > diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst > index 692a3ba56cca..56c560a00b37 100644 > --- a/Documentation/process/security-bugs.rst > +++ b/Documentation/process/security-bugs.rst > @@ -99,9 +99,8 @@ CVE assignment > The security team does not assign CVEs, nor do we require them for > reports or fixes, as this can needlessly complicate the process and may > delay the bug handling. If a reporter wishes to have a CVE identifier > -assigned, they should find one by themselves, for example by contacting > -MITRE directly. However under no circumstances will a patch inclusion > -be delayed to wait for a CVE identifier to arrive. > +assigned for a confirmed issue, they can contact the :doc:`kernel CVE > +assignment team<../process/cve>` to obtain one. > > Non-disclosure agreements > ------------------------- > -- > 2.43.1 > >
On 14/02/2024 09:00, Greg Kroah-Hartman wrote: > diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst > new file mode 100644 > index 000000000000..6465e6a79c18 > --- /dev/null > +++ b/Documentation/process/cve.rst > @@ -0,0 +1,120 @@ > +CVEs > +==== Document titles should have ==== above them as well, and then you would need to shift all the other headings in this document (i.e. all the --- should become ===). Info here: https://docs.kernel.org/doc-guide/sphinx.html#specific-guidelines-for-the-kernel-documentation > +The Linux kernel developer team does have the ability to assign CVEs for > +potential Linux kernel security issues. This assignment is independent > +of the :doc:`normal Linux kernel security bug reporting > +process<../process/security_bugs>`. These documents are both under process/ so it should be enough to say: :doc:`[...] <security-bugs>` In fact, when building the docs with your patch applied, I see: Documentation/process/cve.rst:15: WARNING: unknown document: ./process/security_bugs Documentation/process/cve.rst:42: WARNING: unknown document: ./process/security_bugs Note the hyphen vs. underscore (it should have a hyphen like my line above). > +Process > +------- > + > +As part of the normal stable release process, kernel changes that are > +potentially security issues are identified by the developers responsible > +for CVE number assignments and have CVE numbers automatically assigned > +to them. These assignments are published on the linux-cve-announce > +mailing list as announcements on a frequent basis. > + > +Note, due to the layer at which the Linux kernel is in a system, almost > +any bug might be exploitable to compromise the security of the kernel, > +but the possibility of exploitation is often not evident when the bug is > +fixed. Because of this, the CVE assignment team is overly cautious and What is the composition of the CVE assignment team, or is that secret? Should this be a MAINTAINERS entry? (s@k.org is one.) > +If the CVE assignment team misses a specific fix that any user feels > +should have a CVE assigned to it, please email them at <cve@kernel.org> > +and the team there will work with you on it. Note that no potential > +security issues should be sent to this alias, it is ONLY for assignment > +of CVEs for fixes that are already in released kernel trees. If you > +feel you have found an unfixed security issue, please follow the > +:doc:`normal Linux kernel security bug reporting > +process<../process/security_bugs>`. Same > +Disputes of assigned CVEs > +------------------------- > + > +The authority to dispute or modify an assigned CVE for a specific kernel > +change lies solely with the maintainers of the relevant subsystem > +affected. This principle ensures a high degree of accuracy and > +accountability in vulnerability reporting. Only those individuals with > +deep expertise and intimate knowledge of the subsystem can effectively > +assess the validity and scope of a reported vulnerability and determine > +its appropriate CVE designation. Any attempt to modify or dispute a CVE > +outside of this designated authority could lead to confusion, inaccurate > +reporting, and ultimately, compromised systems. Just to clarify, I think "dispute" here is used in the Mitre/CVE-technical meaning of the word, correct? I assume people will still have the right to say "hey, this doesn't look like a real issue [because of X/Y/Z]" on a mailing list. > --- a/Documentation/process/security-bugs.rst > +++ b/Documentation/process/security-bugs.rst > @@ -99,9 +99,8 @@ CVE assignment > The security team does not assign CVEs, nor do we require them for > reports or fixes, as this can needlessly complicate the process and may > delay the bug handling. If a reporter wishes to have a CVE identifier > -assigned, they should find one by themselves, for example by contacting > -MITRE directly. However under no circumstances will a patch inclusion > -be delayed to wait for a CVE identifier to arrive. > +assigned for a confirmed issue, they can contact the :doc:`kernel CVE > +assignment team<../process/cve>` to obtain one. Same here, this could be just <cve>. Vegard
On 14/02/2024 09:00, Greg Kroah-Hartman wrote: > The Linux kernel project now has the ability to assign CVEs to fixed > issues, so document the process and how individual developers can get a > CVE if one is not automatically assigned for their fixes. > > Reviewed-by: Kees Cook <keescook@chromium.org> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Signed-off-by: Sasha Levin <sashal@kernel.org> > Signed-off-by: Lee Jones <lee@kernel.org> > --- > v3: fix up wording in security-bugs.rst based on the changes to the cve > assignment process from v1, thanks to a private reviewer for > pointing that out. > v2: Grammer fixes based on review from Randy > Updated paragraph about how CVE identifiers will be assigned > (automatically when added to stable trees, or ask us for one > directly before that happens if so desired) > > Documentation/process/cve.rst | 120 ++++++++++++++++++++++++ > Documentation/process/index.rst | 1 + > Documentation/process/security-bugs.rst | 5 +- Great direction! Finally all these bugs we are fixing every release (thus in stable trees) will get proper attention via assigned CVEs. Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Best regards, Krzysztof
On Wed, Feb 14, 2024 at 09:00:30AM +0100, Greg Kroah-Hartman wrote: > +A list of all assigned CVEs for the Linux kernel can be found in the > +archives of the linux-cve mailing list, as seen on > +https://lore.kernel.org/linux-cve-announce/. To get notice of the > +assigned CVEs, please subscribe to that mailing list. Since the archives page doesn't carry any instructions on how to subscribe, I think you should link to https://subspace.kernel.org/subscribing.html here, e.g.: .. please `subscribe <https://subspace.kernel.org/subscribing.html>`_ to that mailing list. > +No CVEs will be assigned for any issue found in a version of the kernel > +that is not currently being actively supported by the Stable/LTS kernel > +team. A list of the currently supported kernel branches can be found at > +https://kernel.org/category/releases.html Can just be https://kernel.org/releases.html Reviewed-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> -K
On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote: > +No CVEs will be automatically assigned for unfixed security issues in > +the Linux kernel; assignment will only automatically happen after a fix > +is available and applied to a stable kernel tree, and it will be tracked > +that way by the git commit id of the original fix. I think this needs way more clarification .. how exactly is this going to work? Do I read this correctly that *everything* that lands in -stable will automatically get CVE assigned? If so, that's just plain crazy. Just took a random peek on the topmost -stable changelog ... ASoC: codecs: wsa883x: fix PA volume control ASoC: codecs: lpass-wsa-macro: fix compander volume hack ASoC: codecs: wcd938x: fix headphones volume controls ASoC: qcom: sc8280xp: limit speaker volumes drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()' Only the last one can *potentially* be considered a CVE candidate, but someone would actually have to take a *deep* look. Most likely it'll be a functional issue, but not a security issue by any measures. So I hope it's not the case, and someone will actually be doing some triage. If that's the case -- is this process described anywhere? Also, how are the CVSS-like scores going to be assigned? There are no details whatsoever about that in the document. In any case, by making this change we are going to make security theathre industry super-happy (they will have a lot of expensive nothing going on), and all the distros not basing on -stable very unhappy (we're already drowning because everybody and his grandma wants to become famous by publishing a CVE for something completely irrelevant). If this is the intention, it should be spelled out loud and clear. Thanks,
On Wed, Feb 14, 2024 at 02:43:48PM +0100, Jiri Kosina wrote: > On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote: > > +No CVEs will be automatically assigned for unfixed security issues in > > +the Linux kernel; assignment will only automatically happen after a fix > > +is available and applied to a stable kernel tree, and it will be tracked > > +that way by the git commit id of the original fix. > I think this needs way more clarification .. how exactly is this going to > work? > Do I read this correctly that *everything* that lands in -stable will > automatically get CVE assigned? If so, that's just plain crazy. Just took > a random peek on the topmost -stable changelog ... > ASoC: codecs: wsa883x: fix PA volume control > ASoC: codecs: lpass-wsa-macro: fix compander volume hack > ASoC: codecs: wcd938x: fix headphones volume controls > ASoC: qcom: sc8280xp: limit speaker volumes > drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()' > Only the last one can *potentially* be considered a CVE candidate, but > someone would actually have to take a *deep* look. Most likely it'll be a > functional issue, but not a security issue by any measures. Not addressing your point in general but the speaker volume limiting is security relevant, that change prevents physical damage to the system. There's an argument for many headphone volume related fixes too since excessively large volumes can cause substantial distress and potential injury to users (I can't remember if that fix would be relevant to that issue).
On Wed, Feb 14, 2024 at 02:43:48PM +0100, Jiri Kosina wrote: > On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote: > > > +No CVEs will be automatically assigned for unfixed security issues in > > +the Linux kernel; assignment will only automatically happen after a fix > > +is available and applied to a stable kernel tree, and it will be tracked > > +that way by the git commit id of the original fix. > > I think this needs way more clarification .. how exactly is this going to > work? > > Do I read this correctly that *everything* that lands in -stable will > automatically get CVE assigned? If so, that's just plain crazy. Just took > a random peek on the topmost -stable changelog ... > > ASoC: codecs: wsa883x: fix PA volume control > ASoC: codecs: lpass-wsa-macro: fix compander volume hack > ASoC: codecs: wcd938x: fix headphones volume controls > ASoC: qcom: sc8280xp: limit speaker volumes > drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()' > > Only the last one can *potentially* be considered a CVE candidate, but > someone would actually have to take a *deep* look. Most likely it'll be a > functional issue, but not a security issue by any measures. > > So I hope it's not the case, and someone will actually be doing some > triage. If that's the case -- is this process described anywhere? It's described as "we know it when we see it" :) Seriously, this is something that Sasha has already been doing successfully for 3+ years now with the GSD project, so look at the commits that have been assigned there for an example of what will be picked. Also we will probably go back in time for a few years and use that data to populate the CVE database for older releases as long as they are still in currently supported releases as this is something that the CVE group has asked us to do already. As for your list above, I doubt any of those would be a CVE, give us some credit here. Let's see how it goes and if people complain we are picking things that we shouldn't be picking, OR if we aren't picking enough, they will then be asked to join the team doing the work :) The people that make up the current team, Lee, Sasha, and I, have a LONG history of fixing and triaging and managing security bugs for the kernel, in the community and in corporate environments. We know how to do this as we have been doing it for decades already. If you or anyone else wishes to help us out with this classification, we can gladly use the help. > Also, how are the CVSS-like scores going to be assigned? There are no > details whatsoever about that in the document. We will not be doing any CVSS scoring as that is outside the scope of a CVE entry and not required at all, and the CVE board agrees with this decision. As you well know, doing something like this for the kernel where we have no idea what your use case is, is almost impossible on the best days. There are external groups that suck in the CVE entries and attempt to assign CVSS-like scores to issues. It will be "interesting" to see how they classify things, but if the history of how well they have done this in the past is any indication, their tools need a lot of work and hopefully people stop relying on them and do the evaluation of their own use cases instead. > In any case, by making this change we are going to make security theathre > industry super-happy (they will have a lot of expensive nothing going on), > and all the distros not basing on -stable very unhappy (we're already > drowning because everybody and his grandma wants to become famous by > publishing a CVE for something completely irrelevant). If this is the > intention, it should be spelled out loud and clear. As we are not allowed to credit anyone in the publication of a CVE, I doubt the "I want a CVE!" group will get any louder than they currently are. And if it generates these people to actually submit bug fixes with their reports, all the better for us! I can't speak to the "security theatre industry" but right now, we have a real problem of external groups assigning random CVEs to the kernel with absolutely no input from us and no accountability, which is causing a lot of us real problems. This will take away the ability for those groups to continue to abuse our project just because of their broken engineering rules, and properly integrate them into our development process if they so desire to join in. thanks, greg k-h
On Wed, Feb 14, 2024 at 01:55:43PM +0000, Mark Brown wrote: > On Wed, Feb 14, 2024 at 02:43:48PM +0100, Jiri Kosina wrote: > > On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote: > > > > +No CVEs will be automatically assigned for unfixed security issues in > > > +the Linux kernel; assignment will only automatically happen after a fix > > > +is available and applied to a stable kernel tree, and it will be tracked > > > +that way by the git commit id of the original fix. > > > I think this needs way more clarification .. how exactly is this going to > > work? > > > Do I read this correctly that *everything* that lands in -stable will > > automatically get CVE assigned? If so, that's just plain crazy. Just took > > a random peek on the topmost -stable changelog ... > > > ASoC: codecs: wsa883x: fix PA volume control > > ASoC: codecs: lpass-wsa-macro: fix compander volume hack > > ASoC: codecs: wcd938x: fix headphones volume controls > > ASoC: qcom: sc8280xp: limit speaker volumes > > drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()' > > > Only the last one can *potentially* be considered a CVE candidate, but > > someone would actually have to take a *deep* look. Most likely it'll be a > > functional issue, but not a security issue by any measures. > > Not addressing your point in general but the speaker volume limiting is > security relevant, that change prevents physical damage to the system. > There's an argument for many headphone volume related fixes too since > excessively large volumes can cause substantial distress and potential > injury to users (I can't remember if that fix would be relevant to that > issue). And this points to the fact that we now have a way, if a maintainer/developer says "hey, that commit could be a potential issue, I want to call that out to others!" they now have a path to do so. Just email cve@kernel.org "can you assign a cve to git id XXXX because of YYY" and we will do so. thanks! greg k-h
On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote: > The people that make up the current team, Lee, Sasha, and I, have a LONG > history of fixing and triaging and managing security bugs for the > kernel, in the community and in corporate environments. We know how to > do this as we have been doing it for decades already. Thanks for clarifying. Maybe the wording could use some more verbosity then; one of my potential readings of it was "everything that gets picked for -stable will get a CVE assigned". > If you or anyone else wishes to help us out with this classification, we > can gladly use the help. Thanks, but no, thanks, I want to stay away from the CVE tragedy as far as possible :)
On Wed, 14 Feb 2024, Mark Brown wrote: > Not addressing your point in general but the speaker volume limiting is > security relevant, that change prevents physical damage to the system. > There's an argument for many headphone volume related fixes too since > excessively large volumes can cause substantial distress and potential > injury to users (I can't remember if that fix would be relevant to that > issue). Thanks, I guess you are actually supporting my point, and that is -- there is no consensus whatsoever of what assigning a CVE actually means, at all. To me -- physical damage to the system, fair enough, that might really easily be security relevant. Something being too loud, causing distress ... that's really a grey zone (to put it mildly) for me. How about e.g. a bug in GPU driver, leading to a flickering screen? Many people are very sensitive to that (both physically and mentally) for various reasons. Bug worth fixing? Absolutely, as soon as possible. Security-relevant? Not in my book. To me, kernel is in no way special, in this respect, actually. With each and every coding error in software of your choice, given anough fantasy, you'll come up with a scenario where this will cause some real issues to some living human. That's not what CVE is about at all, at least in my understaing.
On Wed, Feb 14, 2024 at 03:38:52PM +0100, Jiri Kosina wrote: > On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote: > > > The people that make up the current team, Lee, Sasha, and I, have a LONG > > history of fixing and triaging and managing security bugs for the > > kernel, in the community and in corporate environments. We know how to > > do this as we have been doing it for decades already. > > Thanks for clarifying. Maybe the wording could use some more verbosity > then; one of my potential readings of it was "everything that gets picked > for -stable will get a CVE assigned". CVE has a very specific definition already, as per cve.org: CVE Record is the descriptive data about a vulnerability associated with a CVE ID, provided by a CVE Numbering Authority (CNA). This data is provided in multiple human and machine-readable formats. And they define "vulnerability" as: An instance of one or more weaknesses in a Product that can be exploited, causing a negative impact to confidentiality, integrity, or availability; a set of conditions or behaviors that allows the violation of an explicit or implicit security policy. and as a CNA we must follow that definition. No need to restate the CVE rules in our own document, I am sure that if we don't follow them, lots of people will be quick to point it out and we will revoke those ids that we mess up on. thanks, greg k-h
On Wed, Feb 14, 2024 at 03:46:12PM +0100, Jiri Kosina wrote: > On Wed, 14 Feb 2024, Mark Brown wrote: > > There's an argument for many headphone volume related fixes too since > > excessively large volumes can cause substantial distress and potential > > injury to users (I can't remember if that fix would be relevant to that > > issue). > Something being too loud, causing distress ... that's really a grey zone > (to put it mildly) for me. How about e.g. a bug in GPU driver, leading to > a flickering screen? Many people are very sensitive to that (both > physically and mentally) for various reasons. > Bug worth fixing? Absolutely, as soon as possible. Security-relevant? Not > in my book. To be clear, most headphone drivers can easily generate output levels which will cause temporary or permanent hearing loss after very brief exposure. The distress is the urgent and instinctive need to remove the headphones as fast as possible that tends to result, much as it would for any other ongoing source of injury.
On 14.02.24 09:00, Greg Kroah-Hartman wrote: > The Linux kernel project now has the ability to assign CVEs to fixed > issues, so document the process and how individual developers can get a > CVE if one is not automatically assigned for their fixes. > [...] This following is just nitpicking, hence feel free to ignore. > +As always, it is best to take all released kernel changes, as they are > +tested together in a unified whole by many community members, and not as > +individual cherry-picked changes. Also note that for many bugs, the > +solution to the overall problem is not found in a single change, but by > +the sum of many fixes on top of each other. Ideally CVEs will be > +assigned to all fixes for all issues, but sometimes we do not notice > +fixes in released kernels, so do not assume that because a specific > +change does not have a CVE assigned to it, that it is not relevant to > +take. There are a four "not" in the last pretty long sentence which makes it kinda hard to parse. Avoiding that could look like this: Ideally CVEs will be assigned to all fixes for all issues -- but sometimes we will fail to notice fixes, therefore assume that some changes without an assigned CVE might still be relevant to take. Or like this: Ideally CVEs will be assigned to all fixes for all issues, but sometimes we will overlook fixes -- therefore assume that some changes that lack an assigned CVE might still be relevant to take. Not sure if that really makes it better, I guess you as a native speaker are a better judge here. Ciao, Thorsten (who also wondered what "to all fixes for all issues" exactly means, but whatever)
On Thu, Feb 15, 2024 at 09:17:59AM +0100, Thorsten Leemhuis wrote: > On 14.02.24 09:00, Greg Kroah-Hartman wrote: > > The Linux kernel project now has the ability to assign CVEs to fixed > > issues, so document the process and how individual developers can get a > > CVE if one is not automatically assigned for their fixes. > > [...] > > This following is just nitpicking, hence feel free to ignore. > > > +As always, it is best to take all released kernel changes, as they are > > +tested together in a unified whole by many community members, and not as > > +individual cherry-picked changes. Also note that for many bugs, the > > +solution to the overall problem is not found in a single change, but by > > +the sum of many fixes on top of each other. Ideally CVEs will be > > +assigned to all fixes for all issues, but sometimes we do not notice > > +fixes in released kernels, so do not assume that because a specific > > +change does not have a CVE assigned to it, that it is not relevant to > > +take. > > There are a four "not" in the last pretty long sentence which makes it > kinda hard to parse. Avoiding that could look like this: > > Ideally CVEs will be assigned to all fixes for all issues -- but > sometimes we will fail to notice fixes, therefore assume that some > changes without an assigned CVE might still be relevant to take. > > Or like this: > > Ideally CVEs will be assigned to all fixes for all issues, but sometimes > we will overlook fixes -- therefore assume that some changes that lack > an assigned CVE might still be relevant to take. > > Not sure if that really makes it better, I guess you as a native speaker > are a better judge here. I like the wording change here, thanks, I'll take it for the next revision. It is ackward as I wrote it and your update makes it simpler and more obvious. > Ciao, Thorsten (who also wondered what "to all fixes for all issues" > exactly means, but whatever) Meaning "we will miss things" so don't assume that because we don't call it out here, it's not important to take. Yeah, again, ackward wording, language is "fun"... thanks for the review! greg k-h
On Wed, Feb 14, 2024 at 09:37:31AM +0100, Vegard Nossum wrote: > > On 14/02/2024 09:00, Greg Kroah-Hartman wrote: > > diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst > > new file mode 100644 > > index 000000000000..6465e6a79c18 > > --- /dev/null > > +++ b/Documentation/process/cve.rst > > @@ -0,0 +1,120 @@ > > +CVEs > > +==== > > Document titles should have ==== above them as well, and then you would > need to shift all the other headings in this document (i.e. all the --- > should become ===). > > Info here: https://docs.kernel.org/doc-guide/sphinx.html#specific-guidelines-for-the-kernel-documentation Really? I copied this directly from Documentation/process/security-bugs.rst which is in the format that I used here. Which one is incorrect, I'm confused. > > +The Linux kernel developer team does have the ability to assign CVEs for > > +potential Linux kernel security issues. This assignment is independent > > +of the :doc:`normal Linux kernel security bug reporting > > +process<../process/security_bugs>`. > > These documents are both under process/ so it should be enough to say: > > :doc:`[...] <security-bugs>` > > In fact, when building the docs with your patch applied, I see: > > Documentation/process/cve.rst:15: WARNING: unknown document: > ./process/security_bugs > Documentation/process/cve.rst:42: WARNING: unknown document: > ./process/security_bugs Odd, I would have thought that going back a directory and then into it would work, as that's how filesystems normally are handled :) In fact, again, security-bugs.rst has this very format, which is why I used it, is it throwing that same warning? > Note the hyphen vs. underscore (it should have a hyphen like my line above). Ah, ick, nevermind, my fault, I thought I built this with it added, I'll go fix this up and use the hyphen. > > > +Process > > +------- > > + > > +As part of the normal stable release process, kernel changes that are > > +potentially security issues are identified by the developers responsible > > +for CVE number assignments and have CVE numbers automatically assigned > > +to them. These assignments are published on the linux-cve-announce > > +mailing list as announcements on a frequent basis. > > + > > +Note, due to the layer at which the Linux kernel is in a system, almost > > +any bug might be exploitable to compromise the security of the kernel, > > +but the possibility of exploitation is often not evident when the bug is > > +fixed. Because of this, the CVE assignment team is overly cautious and > > What is the composition of the CVE assignment team, or is that secret? > Should this be a MAINTAINERS entry? (s@k.org is one.) Yeah, it should be a MAINTAINERS entry, I'll add that as part of the next version of this patch. As for the composition, it's not a "secret", but I'd prefer not to list it individually here. As per the signed-off-by on this patch it's Lee, Sasha, and I for now, but I anticipate it will change over time, much like s@k.o has. > > +If the CVE assignment team misses a specific fix that any user feels > > +should have a CVE assigned to it, please email them at <cve@kernel.org> > > +and the team there will work with you on it. Note that no potential > > +security issues should be sent to this alias, it is ONLY for assignment > > +of CVEs for fixes that are already in released kernel trees. If you > > +feel you have found an unfixed security issue, please follow the > > +:doc:`normal Linux kernel security bug reporting > > +process<../process/security_bugs>`. > > Same Thanks, will fix. > > +Disputes of assigned CVEs > > +------------------------- > > + > > +The authority to dispute or modify an assigned CVE for a specific kernel > > +change lies solely with the maintainers of the relevant subsystem > > +affected. This principle ensures a high degree of accuracy and > > +accountability in vulnerability reporting. Only those individuals with > > +deep expertise and intimate knowledge of the subsystem can effectively > > +assess the validity and scope of a reported vulnerability and determine > > +its appropriate CVE designation. Any attempt to modify or dispute a CVE > > +outside of this designated authority could lead to confusion, inaccurate > > +reporting, and ultimately, compromised systems. > > Just to clarify, I think "dispute" here is used in the > Mitre/CVE-technical meaning of the word, correct? I assume people will > still have the right to say "hey, this doesn't look like a real issue > [because of X/Y/Z]" on a mailing list. Yes, mailing list discussion is always good and encouraged and is what is covered here as well. There is the MITRE use of "dispute" as well, and that too is allowed if needed, so this covers both paths. > > > --- a/Documentation/process/security-bugs.rst > > +++ b/Documentation/process/security-bugs.rst > > @@ -99,9 +99,8 @@ CVE assignment > > The security team does not assign CVEs, nor do we require them for > > reports or fixes, as this can needlessly complicate the process and may > > delay the bug handling. If a reporter wishes to have a CVE identifier > > -assigned, they should find one by themselves, for example by contacting > > -MITRE directly. However under no circumstances will a patch inclusion > > -be delayed to wait for a CVE identifier to arrive. > > +assigned for a confirmed issue, they can contact the :doc:`kernel CVE > > +assignment team<../process/cve>` to obtain one. > > Same here, this could be just <cve>. I'll keep it to match the other references in this file :) many thanks for the review! greg k-h
On Wed, Feb 14, 2024 at 08:41:26AM -0500, Konstantin Ryabitsev wrote: > On Wed, Feb 14, 2024 at 09:00:30AM +0100, Greg Kroah-Hartman wrote: > > +A list of all assigned CVEs for the Linux kernel can be found in the > > +archives of the linux-cve mailing list, as seen on > > +https://lore.kernel.org/linux-cve-announce/. To get notice of the > > +assigned CVEs, please subscribe to that mailing list. > > Since the archives page doesn't carry any instructions on how to subscribe, > I think you should link to https://subspace.kernel.org/subscribing.html here, > e.g.: > > .. please `subscribe <https://subspace.kernel.org/subscribing.html>`_ to that > mailing list. > > > +No CVEs will be assigned for any issue found in a version of the kernel > > +that is not currently being actively supported by the Stable/LTS kernel > > +team. A list of the currently supported kernel branches can be found at > > +https://kernel.org/category/releases.html > > Can just be https://kernel.org/releases.html Many thanks for the changes, now made! greg k-h
On Wed, Feb 14, 2024 at 02:10:07PM +0100, Krzysztof Kozlowski wrote: > On 14/02/2024 09:00, Greg Kroah-Hartman wrote: > > The Linux kernel project now has the ability to assign CVEs to fixed > > issues, so document the process and how individual developers can get a > > CVE if one is not automatically assigned for their fixes. > > > > Reviewed-by: Kees Cook <keescook@chromium.org> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Signed-off-by: Sasha Levin <sashal@kernel.org> > > Signed-off-by: Lee Jones <lee@kernel.org> > > --- > > v3: fix up wording in security-bugs.rst based on the changes to the cve > > assignment process from v1, thanks to a private reviewer for > > pointing that out. > > v2: Grammer fixes based on review from Randy > > Updated paragraph about how CVE identifiers will be assigned > > (automatically when added to stable trees, or ask us for one > > directly before that happens if so desired) > > > > Documentation/process/cve.rst | 120 ++++++++++++++++++++++++ > > Documentation/process/index.rst | 1 + > > Documentation/process/security-bugs.rst | 5 +- > > Great direction! Finally all these bugs we are fixing every release > (thus in stable trees) will get proper attention via assigned CVEs. > > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Thanks for the review! greg k-h
On Wed, Feb 14, 2024 at 09:34:38AM +0100, Lukas Bulwahn wrote: > On Wed, Feb 14, 2024 at 9:01 AM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > > > The Linux kernel project now has the ability to assign CVEs to fixed > > issues, so document the process and how individual developers can get a > > CVE if one is not automatically assigned for their fixes. > > > > Reviewed-by: Kees Cook <keescook@chromium.org> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Signed-off-by: Sasha Levin <sashal@kernel.org> > > Signed-off-by: Lee Jones <lee@kernel.org> > > --- > > v3: fix up wording in security-bugs.rst based on the changes to the cve > > assignment process from v1, thanks to a private reviewer for > > pointing that out. > > v2: Grammer fixes based on review from Randy > > Updated paragraph about how CVE identifiers will be assigned > > (automatically when added to stable trees, or ask us for one > > directly before that happens if so desired) > > > > Hi Greg, Sasha, Lee, > > Generally, I think this is a great step forward on the whole "security > vulnerability mess" and this will certainly help me and others in the > embedded space to argue to update to recent stable kernel versions. > This can then finally put the practice of shipping multiple-year-old > kernel versions to an end. Often this was just done with the argument > that there is not a recent CVE and fix assigned to some recent stable > kernel version---and integrators think updates to recent kernel stable > versions are not needed and not recommended. > > I am looking forward to seeing what and how many stable commits are > going to get CVEs assigned. If Greg's policy from the Kernel Recipes > 2019 presentation comes into play, every git kernel hash (GKH)---at > least in the stable tree---could get a CVE identifier (just to be on > the safe side). But I assume you are going to use some expert > knowledge, heuristics or some machine-learning AI to make some commits > in the stable tree carrying a CVE identifier and some others not. Yes, that "expert knowledge" will be "review all patches by hand" just like we do today for all that are included in the stable trees. > Reviewed-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Thanks for the review. > > +Common Vulnerabilities and Exposure (CVE®) numbers were developed as an > > +unambiguous way to identify, define, and catalog publicly disclosed > > +security vulnerabilities. Over time, their usefulness has declined with > > +regards to the kernel project, and CVE numbers were very often assigned > > +in inappropriate ways and for inappropriate reasons. Because of this, > > +the kernel development community has tended to avoid them. However, the > > +combination of continuing pressure to assign CVEs and other forms of > > +security identifiers, and ongoing abuses by community members outside of > > +the kernel community has made it clear that the kernel community should > > +have control over those assignments. > > + > > Though, I get what is meant with "the community members outside of the > kernel community", it still feels strange when reading. > > Here are some alternatives I could come up with: > > "reporters outside the kernel community" > "reporters beyond the actively contributing/engaged kernel community members" > "individuals not engaged with the kernel community" "community members" is a strange wording, you are right, I've replaced it with "individuals and companies" as it has been both abusing the system (and "individuals at companies", but that's just nit-picking...) > > +The Linux kernel developer team does have the ability to assign CVEs for > > +potential Linux kernel security issues. This assignment is independent > > +of the :doc:`normal Linux kernel security bug reporting > > +process<../process/security_bugs>`. > > + > > +A list of all assigned CVEs for the Linux kernel can be found in the > > +archives of the linux-cve mailing list, as seen on > > +https://lore.kernel.org/linux-cve-announce/. To get notice of the > > +assigned CVEs, please subscribe to that mailing list. > > + > > +Process > > +------- > > + > > +As part of the normal stable release process, kernel changes that are > > +potentially security issues are identified by the developers responsible > > +for CVE number assignments and have CVE numbers automatically assigned > > +to them. These assignments are published on the linux-cve-announce > > +mailing list as announcements on a frequent basis. > > + > > +Note, due to the layer at which the Linux kernel is in a system, almost > > +any bug might be exploitable to compromise the security of the kernel, > > Just a nit: but I would say: a kernel bug is compromising the > "security of the system"; the kernel bug just happens to allow anyone > to run any code on their hardware... in some systems that is a > security issue, but in my previous MSDOS system that was the default > behaviour ;) Good change, made, thanks! greg k-h
On 15/02/2024 12:50, Greg Kroah-Hartman wrote: > On Wed, Feb 14, 2024 at 09:37:31AM +0100, Vegard Nossum wrote: >> >> On 14/02/2024 09:00, Greg Kroah-Hartman wrote: >>> diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst >>> new file mode 100644 >>> index 000000000000..6465e6a79c18 >>> --- /dev/null >>> +++ b/Documentation/process/cve.rst >>> @@ -0,0 +1,120 @@ >>> +CVEs >>> +==== >> >> Document titles should have ==== above them as well, and then you would >> need to shift all the other headings in this document (i.e. all the --- >> should become ===). >> >> Info here: https://docs.kernel.org/doc-guide/sphinx.html#specific-guidelines-for-the-kernel-documentation > > Really? I copied this directly from > Documentation/process/security-bugs.rst which is in the format that I > used here. Which one is incorrect, I'm confused. Documentation/ currently has a mix of both formats and they both work, but the guidelines linked above is the gold standard and what we should aim for in new documents. The "correct" format would thus be: ==== CVEs ==== .. Process ======= .. At least this is my understanding; I'm happy to be corrected (and in this case, we should also update the documentation). Thanks for your other clarifications. Vegard
On Wed 14-02-24 09:00:30, Greg KH wrote: [...] > +Process > +------- > + > +As part of the normal stable release process, kernel changes that are > +potentially security issues are identified by the developers responsible > +for CVE number assignments and have CVE numbers automatically assigned > +to them. These assignments are published on the linux-cve-announce > +mailing list as announcements on a frequent basis. > + > +Note, due to the layer at which the Linux kernel is in a system, almost > +any bug might be exploitable to compromise the security of the kernel, > +but the possibility of exploitation is often not evident when the bug is > +fixed. Because of this, the CVE assignment team is overly cautious and > +assign CVE numbers to any bugfix that they identify. This > +explains the seemingly large number of CVEs that are issued by the Linux > +kernel team. Does the process focus only on assigning CVE numbers to a given upstream commit(s) withou any specifics of the actual security threat covered by the said CVE?
On Thu, Feb 15, 2024 at 06:54:17PM +0100, Michal Hocko wrote: > On Wed 14-02-24 09:00:30, Greg KH wrote: > [...] > > +Process > > +------- > > + > > +As part of the normal stable release process, kernel changes that are > > +potentially security issues are identified by the developers responsible > > +for CVE number assignments and have CVE numbers automatically assigned > > +to them. These assignments are published on the linux-cve-announce > > +mailing list as announcements on a frequent basis. > > + > > +Note, due to the layer at which the Linux kernel is in a system, almost > > +any bug might be exploitable to compromise the security of the kernel, > > +but the possibility of exploitation is often not evident when the bug is > > +fixed. Because of this, the CVE assignment team is overly cautious and > > +assign CVE numbers to any bugfix that they identify. This > > +explains the seemingly large number of CVEs that are issued by the Linux > > +kernel team. > > Does the process focus only on assigning CVE numbers to a given upstream > commit(s) withou any specifics of the actual security threat covered by > the said CVE? Outside of the git commit text, no, we are not going to be adding anything additional to the report, UNLESS someone wants to add additional text to it, and then we will be glad to update a CVE entry with the additional information. Here's an example of what the CVE announcement is going to look like for a "test" that we have been doing for our scripts https://lore.kernel.org/linux-cve-announce/2024021353-drainage-unstuffed-a7c0@gregkh/T/#u Note, I am NOT saying this is a valid CVE-like commit, I only chose it because it is a type of entry that our tools need to handle properly (one where the fix was for a commit that was only in a stable tree, and mainline never saw the problem.) There are many different "styles" of fixes that we need to handle when it comes to version information. It will also be in JSON format on the cve.org site if you wish to parse it automatically with tools. We are still working out the proper format of the JSON entries of the version information and should hopefully have an agreement of how to do this early next week, as the logic there isn't exactly "simple". If the announcement format needs additional work, please let us know. thanks, greg k-h
On Thu 15-02-24 19:20:09, Greg KH wrote: > On Thu, Feb 15, 2024 at 06:54:17PM +0100, Michal Hocko wrote: > > On Wed 14-02-24 09:00:30, Greg KH wrote: > > [...] > > > +Process > > > +------- > > > + > > > +As part of the normal stable release process, kernel changes that are > > > +potentially security issues are identified by the developers responsible > > > +for CVE number assignments and have CVE numbers automatically assigned > > > +to them. These assignments are published on the linux-cve-announce > > > +mailing list as announcements on a frequent basis. > > > + > > > +Note, due to the layer at which the Linux kernel is in a system, almost > > > +any bug might be exploitable to compromise the security of the kernel, > > > +but the possibility of exploitation is often not evident when the bug is > > > +fixed. Because of this, the CVE assignment team is overly cautious and > > > +assign CVE numbers to any bugfix that they identify. This > > > +explains the seemingly large number of CVEs that are issued by the Linux > > > +kernel team. > > > > Does the process focus only on assigning CVE numbers to a given upstream > > commit(s) withou any specifics of the actual security threat covered by > > the said CVE? > > Outside of the git commit text, no, we are not going to be adding > anything additional to the report, UNLESS someone wants to add > additional text to it, and then we will be glad to update a CVE entry > with the additional information. OK, so what is the point of having CVE assigned to such a commit without any addional information which is already referenced by the kernel sha? What is the actual added value of that CVE? > Here's an example of what the CVE announcement is going to look like for > a "test" that we have been doing for our scripts > https://lore.kernel.org/linux-cve-announce/2024021353-drainage-unstuffed-a7c0@gregkh/T/#u Thanks this gave me some idea. One worrying part is : Please note that only supported kernel versions have fixes applied to : them. For a full list of currently supported kernel versions, please : see https://www.kernel.org/ From the above it is not really clear "supported by _whom_". Because I am pretty sure there are _fully_ supported kernels outside of that list which are actively maintained.
On Thu, Feb 15, 2024 at 07:20:09PM +0100, Greg Kroah-Hartman wrote: > Here's an example of what the CVE announcement is going to look like for > a "test" that we have been doing for our scripts > https://lore.kernel.org/linux-cve-announce/2024021353-drainage-unstuffed-a7c0@gregkh/T/#u > ... > the latest release is impossible, the individual change to resolve this > issue can be found at: > https://git.kernel.org/stable/linux/c/f08adf5add9a071160c68bb2a61d697f39ab0758 This is the "original fix", a v5.16 commit, which was backported to all the stables. For this case, that seems fine (it's pretty easy to grep the stable trees for the SHA). In the case of a fix only being in -stable, what will be listed for SHAs here? Each stable SHA? Something else?
On Thu, Feb 15, 2024 at 11:40:43AM -0800, Kees Cook wrote: > On Thu, Feb 15, 2024 at 07:20:09PM +0100, Greg Kroah-Hartman wrote: > > Here's an example of what the CVE announcement is going to look like for > > a "test" that we have been doing for our scripts > > https://lore.kernel.org/linux-cve-announce/2024021353-drainage-unstuffed-a7c0@gregkh/T/#u > > ... > > the latest release is impossible, the individual change to resolve this > > issue can be found at: > > https://git.kernel.org/stable/linux/c/f08adf5add9a071160c68bb2a61d697f39ab0758 > > This is the "original fix", a v5.16 commit, which was backported to all > the stables. For this case, that seems fine (it's pretty easy to grep > the stable trees for the SHA). > > In the case of a fix only being in -stable, what will be listed for > SHAs here? Each stable SHA? Something else? I think listing all of the SHA values, stable and mainline, would be best, right? No need for everyone to try to grep the trees, and bonus, the json format has a specific field just for this as well. That's on my todo list for today... thanks, greg k-h
On Thu, 15 Feb 2024, Vegard Nossum <vegard.nossum@oracle.com> wrote: > On 15/02/2024 12:50, Greg Kroah-Hartman wrote: >> On Wed, Feb 14, 2024 at 09:37:31AM +0100, Vegard Nossum wrote: >>> Document titles should have ==== above them as well, and then you would >>> need to shift all the other headings in this document (i.e. all the --- >>> should become ===). >>> >>> Info here: https://docs.kernel.org/doc-guide/sphinx.html#specific-guidelines-for-the-kernel-documentation >> >> Really? I copied this directly from >> Documentation/process/security-bugs.rst which is in the format that I >> used here. Which one is incorrect, I'm confused. > > Documentation/ currently has a mix of both formats and they both work, > but the guidelines linked above is the gold standard and what we should > aim for in new documents. > > The "correct" format would thus be: > > ==== > CVEs > ==== > > ... > > Process > ======= > > ... > > At least this is my understanding; I'm happy to be corrected (and in > this case, we should also update the documentation). rst basically allows any order of the heading underlines, and their relative hierarchy is determined by how they show up in each document, it's not specified by rst. However, it would be much easier for everyone if all the kernel documents followed the same style. BR, Jani.
On Fri, Feb 16, 2024 at 10:28:39AM +0200, Jani Nikula wrote: > On Thu, 15 Feb 2024, Vegard Nossum <vegard.nossum@oracle.com> wrote: > > On 15/02/2024 12:50, Greg Kroah-Hartman wrote: > >> On Wed, Feb 14, 2024 at 09:37:31AM +0100, Vegard Nossum wrote: > >>> Document titles should have ==== above them as well, and then you would > >>> need to shift all the other headings in this document (i.e. all the --- > >>> should become ===). > >>> > >>> Info here: https://docs.kernel.org/doc-guide/sphinx.html#specific-guidelines-for-the-kernel-documentation > >> > >> Really? I copied this directly from > >> Documentation/process/security-bugs.rst which is in the format that I > >> used here. Which one is incorrect, I'm confused. > > > > Documentation/ currently has a mix of both formats and they both work, > > but the guidelines linked above is the gold standard and what we should > > aim for in new documents. > > > > The "correct" format would thus be: > > > > ==== > > CVEs > > ==== > > > > ... > > > > Process > > ======= > > > > ... > > > > At least this is my understanding; I'm happy to be corrected (and in > > this case, we should also update the documentation). > > rst basically allows any order of the heading underlines, and their > relative hierarchy is determined by how they show up in each document, > it's not specified by rst. However, it would be much easier for everyone > if all the kernel documents followed the same style. Agreed, someone should pick a style and sweep the whole directory and sync them up to the agreed formatting. :) thanks, greg k-h
On Thu, Feb 15, 2024 at 07:36:20PM +0100, Michal Hocko wrote: > On Thu 15-02-24 19:20:09, Greg KH wrote: > > On Thu, Feb 15, 2024 at 06:54:17PM +0100, Michal Hocko wrote: > > > On Wed 14-02-24 09:00:30, Greg KH wrote: > > > [...] > > > > +Process > > > > +------- > > > > + > > > > +As part of the normal stable release process, kernel changes that are > > > > +potentially security issues are identified by the developers responsible > > > > +for CVE number assignments and have CVE numbers automatically assigned > > > > +to them. These assignments are published on the linux-cve-announce > > > > +mailing list as announcements on a frequent basis. > > > > + > > > > +Note, due to the layer at which the Linux kernel is in a system, almost > > > > +any bug might be exploitable to compromise the security of the kernel, > > > > +but the possibility of exploitation is often not evident when the bug is > > > > +fixed. Because of this, the CVE assignment team is overly cautious and > > > > +assign CVE numbers to any bugfix that they identify. This > > > > +explains the seemingly large number of CVEs that are issued by the Linux > > > > +kernel team. > > > > > > Does the process focus only on assigning CVE numbers to a given upstream > > > commit(s) withou any specifics of the actual security threat covered by > > > the said CVE? > > > > Outside of the git commit text, no, we are not going to be adding > > anything additional to the report, UNLESS someone wants to add > > additional text to it, and then we will be glad to update a CVE entry > > with the additional information. > > OK, so what is the point of having CVE assigned to such a commit without > any addional information which is already referenced by the kernel sha? > What is the actual added value of that CVE? It provides the proper signal to others that "hey, this is a vulnerability that you might want to take if it affects you". 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. > > Here's an example of what the CVE announcement is going to look like for > > a "test" that we have been doing for our scripts > > https://lore.kernel.org/linux-cve-announce/2024021353-drainage-unstuffed-a7c0@gregkh/T/#u > > Thanks this gave me some idea. One worrying part is > : Please note that only supported kernel versions have fixes applied to > : them. For a full list of currently supported kernel versions, please > : see https://www.kernel.org/ > > >From the above it is not really clear "supported by _whom_". Because I > am pretty sure there are _fully_ supported kernels outside of that list > which are actively maintained. Very true, how about this wording change: For a full list of currently supported kernel versions by the kernel developer community, please see https://www.kernel.org/ I added "by the kernel developer community", is that ok? And as you're here, I have no objection to adding the vulnerable/fixes info from various distros that are curently based on these same kernel.org versions if you wish to provide them to me. Give us a few more days to nail down the version reporting format and then take a look at it to see if you all can tie into that. thanks, greg k-h
On Fri 16-02-24 12:25:46, Greg KH wrote: > On Thu, Feb 15, 2024 at 07:36:20PM +0100, Michal Hocko wrote: > > On Thu 15-02-24 19:20:09, Greg KH wrote: > > > On Thu, Feb 15, 2024 at 06:54:17PM +0100, Michal Hocko wrote: > > > > On Wed 14-02-24 09:00:30, Greg KH wrote: > > > > [...] > > > > > +Process > > > > > +------- > > > > > + > > > > > +As part of the normal stable release process, kernel changes that are > > > > > +potentially security issues are identified by the developers responsible > > > > > +for CVE number assignments and have CVE numbers automatically assigned > > > > > +to them. These assignments are published on the linux-cve-announce > > > > > +mailing list as announcements on a frequent basis. > > > > > + > > > > > +Note, due to the layer at which the Linux kernel is in a system, almost > > > > > +any bug might be exploitable to compromise the security of the kernel, > > > > > +but the possibility of exploitation is often not evident when the bug is > > > > > +fixed. Because of this, the CVE assignment team is overly cautious and > > > > > +assign CVE numbers to any bugfix that they identify. This > > > > > +explains the seemingly large number of CVEs that are issued by the Linux > > > > > +kernel team. > > > > > > > > Does the process focus only on assigning CVE numbers to a given upstream > > > > commit(s) withou any specifics of the actual security threat covered by > > > > the said CVE? > > > > > > Outside of the git commit text, no, we are not going to be adding > > > anything additional to the report, UNLESS someone wants to add > > > additional text to it, and then we will be glad to update a CVE entry > > > with the additional information. > > > > OK, so what is the point of having CVE assigned to such a commit without > > any addional information which is already referenced by the kernel sha? > > What is the actual added value of that CVE? > > It provides the proper signal to others that "hey, this is a > vulnerability that you might want to take if it affects you". OK, but stating that something is a vulnerability fix requires a proper analysis and this is a non trivial work. The wording here indicates that most of the fixes will gain their CVE. The existing process really sucks because there are just too many CVEs which really do not have any security implications but it seems that the new process is not going to address that because it will likely generate even more CVEs. > 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. > > > Here's an example of what the CVE announcement is going to look like for > > > a "test" that we have been doing for our scripts > > > https://lore.kernel.org/linux-cve-announce/2024021353-drainage-unstuffed-a7c0@gregkh/T/#u > > > > Thanks this gave me some idea. One worrying part is > > : Please note that only supported kernel versions have fixes applied to > > : them. For a full list of currently supported kernel versions, please > > : see https://www.kernel.org/ > > > > >From the above it is not really clear "supported by _whom_". Because I > > am pretty sure there are _fully_ supported kernels outside of that list > > which are actively maintained. > > Very true, how about this wording change: > For a full list of currently supported kernel versions by the > kernel developer community, please see https://www.kernel.org/ > > I added "by the kernel developer community", is that ok? That sound much better! > And as you're here, I have no objection to adding the vulnerable/fixes > info from various distros that are curently based on these same > kernel.org versions if you wish to provide them to me. I cannot speak for distro kernels in general. I can tell you that we at Suse do not base our product kernels on stable trees and we carefully evaluate backports we commit to support.
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
On Fri 16-02-24 16:34:57, Greg KH wrote: > 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. Right, generally speaking this is not an easy task. It requires a lot of diligence actually. Sometimes there is no clear cut and that is _fine_. The CVE system cannot ever be bullet proof and mark every single security related fix (really you can be creating new security problems just by backporting upstream fixes into stable trees). But that is not really all that important, the main thing/question is whether it can be _useful_. If you simply assign CVE to any fix in stable you end up with thousands of CVEs and I really fail to see any practical benefit from that. Well, unless you want to DoS the system and its consumers. Who do you expect to be the user/consumer of those CVE numbers? You have already said that community supported stable kernels mandate the latest version to be used. Those users do not need to know there is $BIG_NUMBER of CVEs in them. If you want to mark a specific class of fixes with CVE because they are known to be used for exploits then fine! That is something actually useful. If you allow users to explicitly mark a fix as security relevant because of XYZ argument then really great! > 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. I am completely with you on that! That is quite far away from what the documentation says AFAICS. > 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. I've been through that exercise with the CVE process over years many times. It has always been a pain because you were not talking to domain experts who could evaluate the reasoning behind the dispute. I consider the new process of a clearly defined dispute process a big improvement! But if the real practice would be thousands of CVEs created for any stable backport then this will DoS many existing CVE consumers. All that being said. I do agree that taking control of CVEs and making that kernel community thing is a good thing! But I really fail to understand how increasing the number of CVEs by nominating all/most stable fixes is going to help anybody or improve the existing process. Thanks!
diff --git a/Documentation/process/cve.rst b/Documentation/process/cve.rst new file mode 100644 index 000000000000..6465e6a79c18 --- /dev/null +++ b/Documentation/process/cve.rst @@ -0,0 +1,120 @@ +CVEs +==== + +Common Vulnerabilities and Exposure (CVE®) numbers were developed as an +unambiguous way to identify, define, and catalog publicly disclosed +security vulnerabilities. Over time, their usefulness has declined with +regards to the kernel project, and CVE numbers were very often assigned +in inappropriate ways and for inappropriate reasons. Because of this, +the kernel development community has tended to avoid them. However, the +combination of continuing pressure to assign CVEs and other forms of +security identifiers, and ongoing abuses by community members outside of +the kernel community has made it clear that the kernel community should +have control over those assignments. + +The Linux kernel developer team does have the ability to assign CVEs for +potential Linux kernel security issues. This assignment is independent +of the :doc:`normal Linux kernel security bug reporting +process<../process/security_bugs>`. + +A list of all assigned CVEs for the Linux kernel can be found in the +archives of the linux-cve mailing list, as seen on +https://lore.kernel.org/linux-cve-announce/. To get notice of the +assigned CVEs, please subscribe to that mailing list. + +Process +------- + +As part of the normal stable release process, kernel changes that are +potentially security issues are identified by the developers responsible +for CVE number assignments and have CVE numbers automatically assigned +to them. These assignments are published on the linux-cve-announce +mailing list as announcements on a frequent basis. + +Note, due to the layer at which the Linux kernel is in a system, almost +any bug might be exploitable to compromise the security of the kernel, +but the possibility of exploitation is often not evident when the bug is +fixed. Because of this, the CVE assignment team is overly cautious and +assign CVE numbers to any bugfix that they identify. This +explains the seemingly large number of CVEs that are issued by the Linux +kernel team. + +If the CVE assignment team misses a specific fix that any user feels +should have a CVE assigned to it, please email them at <cve@kernel.org> +and the team there will work with you on it. Note that no potential +security issues should be sent to this alias, it is ONLY for assignment +of CVEs for fixes that are already in released kernel trees. If you +feel you have found an unfixed security issue, please follow the +:doc:`normal Linux kernel security bug reporting +process<../process/security_bugs>`. + +No CVEs will be automatically assigned for unfixed security issues in +the Linux kernel; assignment will only automatically happen after a fix +is available and applied to a stable kernel tree, and it will be tracked +that way by the git commit id of the original fix. If anyone wishes to +have a CVE assigned before an issue is resolved with a commit, please +contact the kernel CVE assignment team at <cve@kernel.org> to get an +identifier assigned from their batch of reserved identifiers. + +No CVEs will be assigned for any issue found in a version of the kernel +that is not currently being actively supported by the Stable/LTS kernel +team. A list of the currently supported kernel branches can be found at +https://kernel.org/category/releases.html + +Disputes of assigned CVEs +------------------------- + +The authority to dispute or modify an assigned CVE for a specific kernel +change lies solely with the maintainers of the relevant subsystem +affected. This principle ensures a high degree of accuracy and +accountability in vulnerability reporting. Only those individuals with +deep expertise and intimate knowledge of the subsystem can effectively +assess the validity and scope of a reported vulnerability and determine +its appropriate CVE designation. Any attempt to modify or dispute a CVE +outside of this designated authority could lead to confusion, inaccurate +reporting, and ultimately, compromised systems. + +Invalid CVEs +------------ + +If a security issue is found in a Linux kernel that is only supported by +a Linux distribution due to the changes that have been made by that +distribution, or due to the distribution supporting a kernel version +that is no longer one of the kernel.org supported releases, then a CVE +can not be assigned by the Linux kernel CVE team, and must be asked for +from that Linux distribution itself. + +Any CVE that is assigned against the Linux kernel for an actively +supported kernel version, by any group other than the kernel assignment +CVE team should not be treated as a valid CVE. Please notify the +kernel CVE assignment team at <cve@kernel.org> so that they can work to +invalidate such entries through the CNA remediation process. + +Applicability of specific CVEs +------------------------------ + +As the Linux kernel can be used in many different ways, with many +different ways of accessing it by external users, or no access at all, +the applicability of any specific CVE is up to the user of Linux to +determine, it is not up to the CVE assignment team. Please do not +contact us to attempt to determine the applicability of any specific +CVE. + +Also, as the source tree is so large, and any one system only uses a +small subset of the source tree, any users of Linux should be aware that +large numbers of assigned CVEs are not relevant for their systems. + +In short, we do not know your use case, and we do not know what portions +of the kernel that you use, so there is no way for us to determine if a +specific CVE is relevant for your system. + +As always, it is best to take all released kernel changes, as they are +tested together in a unified whole by many community members, and not as +individual cherry-picked changes. Also note that for many bugs, the +solution to the overall problem is not found in a single change, but by +the sum of many fixes on top of each other. Ideally CVEs will be +assigned to all fixes for all issues, but sometimes we do not notice +fixes in released kernels, so do not assume that because a specific +change does not have a CVE assigned to it, that it is not relevant to +take. + diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index 6cb732dfcc72..de9cbb7bd7eb 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -81,6 +81,7 @@ of special classes of bugs: regressions and security problems. handling-regressions security-bugs + cve embargoed-hardware-issues Maintainer information diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst index 692a3ba56cca..56c560a00b37 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -99,9 +99,8 @@ CVE assignment The security team does not assign CVEs, nor do we require them for reports or fixes, as this can needlessly complicate the process and may delay the bug handling. If a reporter wishes to have a CVE identifier -assigned, they should find one by themselves, for example by contacting -MITRE directly. However under no circumstances will a patch inclusion -be delayed to wait for a CVE identifier to arrive. +assigned for a confirmed issue, they can contact the :doc:`kernel CVE +assignment team<../process/cve>` to obtain one. Non-disclosure agreements -------------------------