Commit 544b03da authored by Will Deacon's avatar Will Deacon Committed by Greg Kroah-Hartman

Documentation/security-bugs: Postpone fix publication in exceptional cases

At the request of the reporter, the Linux kernel security team offers to
postpone the publishing of a fix for up to 5 business days from the date
of a report.

While it is generally undesirable to keep a fix private after it has
been developed, this short window is intended to allow distributions to
package the fix into their kernel builds and permits early inclusion of
the security team in the case of a co-ordinated disclosure with other
parties. Unfortunately, discussions with major Linux distributions and
cloud providers has revealed that 5 business days is not sufficient to
achieve either of these two goals.

As an example, cloud providers need to roll out KVM security fixes to a
global fleet of hosts with sufficient early ramp-up and monitoring. An
end-to-end timeline of less than two weeks dramatically cuts into the
amount of early validation and increases the chance of guest-visible
regressions.

The consequence of this timeline mismatch is that security issues are
commonly fixed without the involvement of the Linux kernel security team
and are instead analysed and addressed by an ad-hoc group of developers
across companies contributing to Linux. In some cases, mainline (and
therefore the official stable kernels) can be left to languish for
extended periods of time. This undermines the Linux kernel security
process and puts upstream developers in a difficult position should they
find themselves involved with an undisclosed security problem that they
are unable to report due to restrictions from their employer.

To accommodate the needs of these users of the Linux kernel and
encourage them to engage with the Linux security team when security
issues are first uncovered, extend the maximum period for which fixes
may be delayed to 7 calendar days, or 14 calendar days in exceptional
cases, where the logistics of QA and large scale rollouts specifically
need to be accommodated. This brings parity with the linux-distros@
maximum embargo period of 14 calendar days.

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Amit Shah <aams@amazon.com>
Cc: Laura Abbott <labbott@redhat.com>
Acked-by: default avatarKees Cook <keescook@chromium.org>
Co-developed-by: default avatarThomas Gleixner <tglx@linutronix.de>
Co-developed-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
Reviewed-by: default avatarTyler Hicks <tyhicks@canonical.com>
Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
parent cb5d2194
...@@ -32,16 +32,17 @@ Disclosure and embargoed information ...@@ -32,16 +32,17 @@ Disclosure and embargoed information
The security list is not a disclosure channel. For that, see Coordination The security list is not a disclosure channel. For that, see Coordination
below. below.
Once a robust fix has been developed, our preference is to release the Once a robust fix has been developed, the release process starts. Fixes
fix in a timely fashion, treating it no differently than any of the other for publicly known bugs are released immediately.
thousands of changes and fixes the Linux kernel project releases every
month. Although our preference is to release fixes for publicly undisclosed bugs
as soon as they become available, this may be postponed at the request of
However, at the request of the reporter, we will postpone releasing the the reporter or an affected party for up to 7 calendar days from the start
fix for up to 5 business days after the date of the report or after the of the release process, with an exceptional extension to 14 calendar days
embargo has lifted; whichever comes first. The only exception to that if it is agreed that the criticality of the bug requires more time. The
rule is if the bug is publicly known, in which case the preference is to only valid reason for deferring the publication of a fix is to accommodate
release the fix as soon as it's available. the logistics of QA and large scale rollouts which require release
coordination.
Whilst embargoed information may be shared with trusted individuals in Whilst embargoed information may be shared with trusted individuals in
order to develop a fix, such information will not be published alongside order to develop a fix, such information will not be published alongside
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment