Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Cross-merge networking fixes after downstream PR. net/mac80211/key.c02e0e426a2("wifi: mac80211: fix error path key leak")2a8b665e6b("wifi: mac80211: remove key_mtx")7d6904bf26("Merge wireless into wireless-next") https://lore.kernel.org/all/20231012113648.46eea5ec@canb.auug.org.au/ Adjacent changes: drivers/net/ethernet/ti/Kconfiga602ee3176("net: ethernet: ti: Fix mixed module-builtin object")98bdeae950("net: cpmac: remove driver to prepare for platform removal") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This commit is contained in:
@@ -25,15 +25,15 @@ Contact
|
||||
The Linux kernel hardware security team is separate from the regular Linux
|
||||
kernel security team.
|
||||
|
||||
The team only handles the coordination of embargoed hardware security
|
||||
issues. Reports of pure software security bugs in the Linux kernel are not
|
||||
The team only handles developing fixes for embargoed hardware security
|
||||
issues. Reports of pure software security bugs in the Linux kernel are not
|
||||
handled by this team and the reporter will be guided to contact the regular
|
||||
Linux kernel security team (:ref:`Documentation/admin-guide/
|
||||
<securitybugs>`) instead.
|
||||
|
||||
The team can be contacted by email at <hardware-security@kernel.org>. This
|
||||
is a private list of security officers who will help you to coordinate an
|
||||
issue according to our documented process.
|
||||
is a private list of security officers who will help you to coordinate a
|
||||
fix according to our documented process.
|
||||
|
||||
The list is encrypted and email to the list can be sent by either PGP or
|
||||
S/MIME encrypted and must be signed with the reporter's PGP key or S/MIME
|
||||
@@ -132,11 +132,11 @@ other hardware could be affected.
|
||||
|
||||
The hardware security team will provide an incident-specific encrypted
|
||||
mailing-list which will be used for initial discussion with the reporter,
|
||||
further disclosure and coordination.
|
||||
further disclosure, and coordination of fixes.
|
||||
|
||||
The hardware security team will provide the disclosing party a list of
|
||||
developers (domain experts) who should be informed initially about the
|
||||
issue after confirming with the developers that they will adhere to this
|
||||
issue after confirming with the developers that they will adhere to this
|
||||
Memorandum of Understanding and the documented process. These developers
|
||||
form the initial response team and will be responsible for handling the
|
||||
issue after initial contact. The hardware security team is supporting the
|
||||
@@ -209,13 +209,18 @@ five work days this is taken as silent acknowledgement.
|
||||
After acknowledgement or resolution of an objection the expert is disclosed
|
||||
by the incident team and brought into the development process.
|
||||
|
||||
List participants may not communicate about the issue outside of the
|
||||
private mailing list. List participants may not use any shared resources
|
||||
(e.g. employer build farms, CI systems, etc) when working on patches.
|
||||
|
||||
|
||||
Coordinated release
|
||||
"""""""""""""""""""
|
||||
|
||||
The involved parties will negotiate the date and time where the embargo
|
||||
ends. At that point the prepared mitigations are integrated into the
|
||||
relevant kernel trees and published.
|
||||
relevant kernel trees and published. There is no pre-notification process:
|
||||
fixes are published in public and available to everyone at the same time.
|
||||
|
||||
While we understand that hardware security issues need coordinated embargo
|
||||
time, the embargo time should be constrained to the minimum time which is
|
||||
|
||||
Reference in New Issue
Block a user