€•’¨      Œsphinx.addnodes”Œdocument”“”)”}”(Œ	rawsource”Œ ”Œchildren”]”(Œtranslations”ŒLanguagesNode”“”)”}”(hhh]”(h Œpending_xref”“”)”}”(hhh]”Œdocutils.nodes”ŒText”“”ŒChinese (Simplified)”…””}”Œparent”hsbaŒ
attributes”}”(Œids”]”Œclasses”]”Œnames”]”Œdupnames”]”Œbackrefs”]”Œ	refdomain”Œstd”Œreftype”Œdoc”Œ	reftarget”Œ)/translations/zh_CN/process/security-bugs”Œmodname”NŒ	classname”NŒrefexplicit”ˆuŒtagname”hhhubh)”}”(hhh]”hŒChinese (Traditional)”…””}”hh2sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ)/translations/zh_TW/process/security-bugs”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒItalian”…””}”hhFsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ)/translations/it_IT/process/security-bugs”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒJapanese”…””}”hhZsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ)/translations/ja_JP/process/security-bugs”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒKorean”…””}”hhnsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ)/translations/ko_KR/process/security-bugs”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒSpanish”…””}”hh‚sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ)/translations/sp_SP/process/security-bugs”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubeh}”(h]”h ]”h"]”h$]”h&]”Œcurrent_language”ŒEnglish”uh1h
hhŒ	_document”hŒsource”NŒline”NubhŒtarget”“”)”}”(hŒ.. _securitybugs:”h]”h}”(h]”h ]”h"]”h$]”h&]”Œrefid”Œsecuritybugs”uh1h¡h KhhhžhhŸŒC/var/lib/git/docbuild/linux/Documentation/process/security-bugs.rst”ubhŒsection”“”)”}”(hhh]”(hŒtitle”“”)”}”(hŒSecurity bugs”h]”hŒSecurity bugs”…””}”(hh·hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hµhh²hžhhŸh¯h KubhŒ	paragraph”“”)”}”(hŒ¬Linux kernel developers take security very seriously.  As such, we'd
like to know when a security bug is found so that it can be fixed and
disclosed as quickly as possible.”h]”hŒ®Linux kernel developers take security very seriously.  As such, weâ€™d
like to know when a security bug is found so that it can be fixed and
disclosed as quickly as possible.”…””}”(hhÇhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h Khh²hžhubh±)”}”(hhh]”(h¶)”}”(hŒPreparing your report”h]”hŒPreparing your report”…””}”(hhØhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hµhhÕhžhhŸh¯h KubhÆ)”}”(hX‰  Like with any bug report, a security bug report requires a lot of analysis work
from the developers, so the more information you can share about the issue, the
better.  Please review the procedure outlined in
Documentation/admin-guide/reporting-issues.rst if you are unclear about what
information is helpful.  The following information are absolutely necessary in
**any** security bug report:”h]”(hXm  Like with any bug report, a security bug report requires a lot of analysis work
from the developers, so the more information you can share about the issue, the
better.  Please review the procedure outlined in
Documentation/admin-guide/reporting-issues.rst if you are unclear about what
information is helpful.  The following information are absolutely necessary in
”…””}”(hhæhžhhŸNh NubhŒstrong”“”)”}”(hŒ**any**”h]”hŒany”…””}”(hhðhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîhhæubhŒ security bug report:”…””}”(hhæhžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h KhhÕhžhubhŒblock_quote”“”)”}”(hXn  * **affected kernel version range**: with no version indication, your report
  will not be processed.  A significant part of reports are for bugs that
  have already been fixed, so it is extremely important that vulnerabilities
  are verified on recent versions (development tree or latest stable
  version), at least by verifying that the code has not changed since the
  version where it was detected.

* **description of the problem**: a detailed description of the problem, with
  traces showing its manifestation, and why you consider that the observed
  behavior as a problem in the kernel, is necessary.

* **reproducer**: developers will need to be able to reproduce the problem to
  consider a fix as effective.  This includes both a way to trigger the issue
  and a way to confirm it happens.  A reproducer with low complexity
  dependencies will be needed (source code, shell script, sequence of
  instructions, file-system image etc).  Binary-only executables are not
  accepted.  Working exploits are extremely helpful and will not be released
  without consent from the reporter, unless they are already public.  By
  definition if an issue cannot be reproduced, it is not exploitable, thus it
  is not a security bug.

* **conditions**: if the bug depends on certain configuration options,
  sysctls, permissions, timing, code modifications etc, these should be
  indicated.
”h]”hŒbullet_list”“”)”}”(hhh]”(hŒ	list_item”“”)”}”(hXˆ  **affected kernel version range**: with no version indication, your report
will not be processed.  A significant part of reports are for bugs that
have already been fixed, so it is extremely important that vulnerabilities
are verified on recent versions (development tree or latest stable
version), at least by verifying that the code has not changed since the
version where it was detected.
”h]”hÆ)”}”(hX‡  **affected kernel version range**: with no version indication, your report
will not be processed.  A significant part of reports are for bugs that
have already been fixed, so it is extremely important that vulnerabilities
are verified on recent versions (development tree or latest stable
version), at least by verifying that the code has not changed since the
version where it was detected.”h]”(hï)”}”(hŒ!**affected kernel version range**”h]”hŒaffected kernel version range”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîhj  ubhXf  : with no version indication, your report
will not be processed.  A significant part of reports are for bugs that
have already been fixed, so it is extremely important that vulnerabilities
are verified on recent versions (development tree or latest stable
version), at least by verifying that the code has not changed since the
version where it was detected.”…””}”(hj  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h Khj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj  ubj  )”}”(hŒÈ**description of the problem**: a detailed description of the problem, with
traces showing its manifestation, and why you consider that the observed
behavior as a problem in the kernel, is necessary.
”h]”hÆ)”}”(hŒÇ**description of the problem**: a detailed description of the problem, with
traces showing its manifestation, and why you consider that the observed
behavior as a problem in the kernel, is necessary.”h]”(hï)”}”(hŒ**description of the problem**”h]”hŒdescription of the problem”…””}”(hjC  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîhj?  ubhŒ©: a detailed description of the problem, with
traces showing its manifestation, and why you consider that the observed
behavior as a problem in the kernel, is necessary.”…””}”(hj?  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h Khj;  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj  ubj  )”}”(hX[  **reproducer**: developers will need to be able to reproduce the problem to
consider a fix as effective.  This includes both a way to trigger the issue
and a way to confirm it happens.  A reproducer with low complexity
dependencies will be needed (source code, shell script, sequence of
instructions, file-system image etc).  Binary-only executables are not
accepted.  Working exploits are extremely helpful and will not be released
without consent from the reporter, unless they are already public.  By
definition if an issue cannot be reproduced, it is not exploitable, thus it
is not a security bug.
”h]”hÆ)”}”(hXZ  **reproducer**: developers will need to be able to reproduce the problem to
consider a fix as effective.  This includes both a way to trigger the issue
and a way to confirm it happens.  A reproducer with low complexity
dependencies will be needed (source code, shell script, sequence of
instructions, file-system image etc).  Binary-only executables are not
accepted.  Working exploits are extremely helpful and will not be released
without consent from the reporter, unless they are already public.  By
definition if an issue cannot be reproduced, it is not exploitable, thus it
is not a security bug.”h]”(hï)”}”(hŒ**reproducer**”h]”hŒ
reproducer”…””}”(hji  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîhje  ubhXL  : developers will need to be able to reproduce the problem to
consider a fix as effective.  This includes both a way to trigger the issue
and a way to confirm it happens.  A reproducer with low complexity
dependencies will be needed (source code, shell script, sequence of
instructions, file-system image etc).  Binary-only executables are not
accepted.  Working exploits are extremely helpful and will not be released
without consent from the reporter, unless they are already public.  By
definition if an issue cannot be reproduced, it is not exploitable, thus it
is not a security bug.”…””}”(hje  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h Khja  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj  ubj  )”}”(hŒ–**conditions**: if the bug depends on certain configuration options,
sysctls, permissions, timing, code modifications etc, these should be
indicated.
”h]”hÆ)”}”(hŒ•**conditions**: if the bug depends on certain configuration options,
sysctls, permissions, timing, code modifications etc, these should be
indicated.”h]”(hï)”}”(hŒ**conditions**”h]”hŒ
conditions”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîhj‹  ubhŒ‡: if the bug depends on certain configuration options,
sysctls, permissions, timing, code modifications etc, these should be
indicated.”…””}”(hj‹  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h K)hj‡  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj  ubeh}”(h]”h ]”h"]”h$]”h&]”Œbullet”Œ*”uh1j  hŸh¯h Khj
  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hŸh¯h KhhÕhžhubhÆ)”}”(hŒ<In addition, the following information are highly desirable:”h]”hŒ<In addition, the following information are highly desirable:”…””}”(hj»  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h K-hhÕhžhubj	  )”}”(hXI  * **suspected location of the bug**: the file names and functions where the
  bug is suspected to be present are very important, at least to help forward
  the report to the appropriate maintainers.  When not possible (for example,
  "system freezes each time I run this command"), the security team will help
  identify the source of the bug.

* **a proposed fix**: bug reporters who have analyzed the cause of a bug in
  the source code almost always have an accurate idea on how to fix it,
  because they spent a long time studying it and its implications.  Proposing
  a tested fix will save maintainers a lot of time, even if the fix ends up
  not being the right one, because it helps understand the bug.  When
  proposing a tested fix, please always format it in a way that can be
  immediately merged (see Documentation/process/submitting-patches.rst).
  This will save some back-and-forth exchanges if it is accepted, and you
  will be credited for finding and fixing this issue.  Note that in this case
  only a ``Signed-off-by:`` tag is needed, without ``Reported-by:`` when the
  reporter and author are the same.

* **mitigations**: very often during a bug analysis, some ways of mitigating
  the issue appear. It is useful to share them, as they can be helpful to
  keep end users protected during the time it takes them to apply the fix.
”h]”j  )”}”(hhh]”(j  )”}”(hXN  **suspected location of the bug**: the file names and functions where the
bug is suspected to be present are very important, at least to help forward
the report to the appropriate maintainers.  When not possible (for example,
"system freezes each time I run this command"), the security team will help
identify the source of the bug.
”h]”hÆ)”}”(hXM  **suspected location of the bug**: the file names and functions where the
bug is suspected to be present are very important, at least to help forward
the report to the appropriate maintainers.  When not possible (for example,
"system freezes each time I run this command"), the security team will help
identify the source of the bug.”h]”(hï)”}”(hŒ!**suspected location of the bug**”h]”hŒsuspected location of the bug”…””}”(hjØ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîhjÔ  ubhX0  : the file names and functions where the
bug is suspected to be present are very important, at least to help forward
the report to the appropriate maintainers.  When not possible (for example,
â€œsystem freezes each time I run this commandâ€), the security team will help
identify the source of the bug.”…””}”(hjÔ  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h K/hjÐ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hjÍ  ubj  )”}”(hX÷  **a proposed fix**: bug reporters who have analyzed the cause of a bug in
the source code almost always have an accurate idea on how to fix it,
because they spent a long time studying it and its implications.  Proposing
a tested fix will save maintainers a lot of time, even if the fix ends up
not being the right one, because it helps understand the bug.  When
proposing a tested fix, please always format it in a way that can be
immediately merged (see Documentation/process/submitting-patches.rst).
This will save some back-and-forth exchanges if it is accepted, and you
will be credited for finding and fixing this issue.  Note that in this case
only a ``Signed-off-by:`` tag is needed, without ``Reported-by:`` when the
reporter and author are the same.
”h]”hÆ)”}”(hXö  **a proposed fix**: bug reporters who have analyzed the cause of a bug in
the source code almost always have an accurate idea on how to fix it,
because they spent a long time studying it and its implications.  Proposing
a tested fix will save maintainers a lot of time, even if the fix ends up
not being the right one, because it helps understand the bug.  When
proposing a tested fix, please always format it in a way that can be
immediately merged (see Documentation/process/submitting-patches.rst).
This will save some back-and-forth exchanges if it is accepted, and you
will be credited for finding and fixing this issue.  Note that in this case
only a ``Signed-off-by:`` tag is needed, without ``Reported-by:`` when the
reporter and author are the same.”h]”(hï)”}”(hŒ**a proposed fix**”h]”hŒa proposed fix”…””}”(hjþ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîhjú  ubhX  : bug reporters who have analyzed the cause of a bug in
the source code almost always have an accurate idea on how to fix it,
because they spent a long time studying it and its implications.  Proposing
a tested fix will save maintainers a lot of time, even if the fix ends up
not being the right one, because it helps understand the bug.  When
proposing a tested fix, please always format it in a way that can be
immediately merged (see Documentation/process/submitting-patches.rst).
This will save some back-and-forth exchanges if it is accepted, and you
will be credited for finding and fixing this issue.  Note that in this case
only a ”…””}”(hjú  hžhhŸNh NubhŒliteral”“”)”}”(hŒ``Signed-off-by:``”h]”hŒSigned-off-by:”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hjú  ubhŒ tag is needed, without ”…””}”(hjú  hžhhŸNh Nubj  )”}”(hŒ``Reported-by:``”h]”hŒReported-by:”…””}”(hj$  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hjú  ubhŒ+ when the
reporter and author are the same.”…””}”(hjú  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h K5hjö  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hjÍ  ubj  )”}”(hŒÜ**mitigations**: very often during a bug analysis, some ways of mitigating
the issue appear. It is useful to share them, as they can be helpful to
keep end users protected during the time it takes them to apply the fix.
”h]”hÆ)”}”(hŒÛ**mitigations**: very often during a bug analysis, some ways of mitigating
the issue appear. It is useful to share them, as they can be helpful to
keep end users protected during the time it takes them to apply the fix.”h]”(hï)”}”(hŒ**mitigations**”h]”hŒmitigations”…””}”(hjJ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîhjF  ubhŒÌ: very often during a bug analysis, some ways of mitigating
the issue appear. It is useful to share them, as they can be helpful to
keep end users protected during the time it takes them to apply the fix.”…””}”(hjF  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h KAhjB  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hjÍ  ubeh}”(h]”h ]”h"]”h$]”h&]”j³  j´  uh1j  hŸh¯h K/hjÉ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hŸh¯h K/hhÕhžhubeh}”(h]”Œpreparing-your-report”ah ]”h"]”Œpreparing your report”ah$]”h&]”uh1h°hh²hžhhŸh¯h Kubh±)”}”(hhh]”(h¶)”}”(hŒIdentifying contacts”h]”hŒIdentifying contacts”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hµhj|  hžhhŸh¯h KFubhÆ)”}”(hXŠ  The most effective way to report a security bug is to send it directly to the
affected subsystem's maintainers and Cc: the Linux kernel security team.  Do
not send it to a public list at this stage, unless you have good reasons to
consider the issue as being public or trivial to discover (e.g. result of a
widely available automated vulnerability scanning tool that can be repeated by
anyone).”h]”hXŒ  The most effective way to report a security bug is to send it directly to the
affected subsystemâ€™s maintainers and Cc: the Linux kernel security team.  Do
not send it to a public list at this stage, unless you have good reasons to
consider the issue as being public or trivial to discover (e.g. result of a
widely available automated vulnerability scanning tool that can be repeated by
anyone).”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h KHhj|  hžhubhÆ)”}”(hXÑ  If you're sending a report for issues affecting multiple parts in the kernel,
even if they're fairly similar issues, please send individual messages (think
that maintainers will not all work on the issues at the same time). The only
exception is when an issue concerns closely related parts maintained by the
exact same subset of maintainers, and these parts are expected to be fixed all
at once by the same commit, then it may be acceptable to report them at once.”h]”hXÕ  If youâ€™re sending a report for issues affecting multiple parts in the kernel,
even if theyâ€™re fairly similar issues, please send individual messages (think
that maintainers will not all work on the issues at the same time). The only
exception is when an issue concerns closely related parts maintained by the
exact same subset of maintainers, and these parts are expected to be fixed all
at once by the same commit, then it may be acceptable to report them at once.”…””}”(hj›  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h KOhj|  hžhubhÆ)”}”(hXý  One difficulty for most first-time reporters is to figure the right list of
recipients to send a report to.  In the Linux kernel, all official maintainers
are trusted, so the consequences of accidentally including the wrong maintainer
are essentially a bit more noise for that person, i.e. nothing dramatic.  As
such, a suitable method to figure the list of maintainers (which kernel
security officers use) is to rely on the get_maintainer.pl script, tuned to
only report maintainers.  This script, when passed a file name, will look for
its path in the MAINTAINERS file to figure a hierarchical list of relevant
maintainers.  Calling it a first time with the finest level of filtering will
most of the time return a short list of this specific file's maintainers::”h]”hXþ  One difficulty for most first-time reporters is to figure the right list of
recipients to send a report to.  In the Linux kernel, all official maintainers
are trusted, so the consequences of accidentally including the wrong maintainer
are essentially a bit more noise for that person, i.e. nothing dramatic.  As
such, a suitable method to figure the list of maintainers (which kernel
security officers use) is to rely on the get_maintainer.pl script, tuned to
only report maintainers.  This script, when passed a file name, will look for
its path in the MAINTAINERS file to figure a hierarchical list of relevant
maintainers.  Calling it a first time with the finest level of filtering will
most of the time return a short list of this specific fileâ€™s maintainers:”…””}”(hj©  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h KVhj|  hžhubhŒliteral_block”“”)”}”(hŒÍ$ ./scripts/get_maintainer.pl --no-l --no-r --pattern-depth 1 \
  drivers/example.c
Developer One <dev1@example.com> (maintainer:example driver)
Developer Two <dev2@example.org> (maintainer:example driver)”h]”hŒÍ$ ./scripts/get_maintainer.pl --no-l --no-r --pattern-depth 1 \
  drivers/example.c
Developer One <dev1@example.com> (maintainer:example driver)
Developer Two <dev2@example.org> (maintainer:example driver)”…””}”hj¹  sbah}”(h]”h ]”h"]”h$]”h&]”Œ	xml:space”Œpreserve”uh1j·  hŸh¯h Kahj|  hžhubhÆ)”}”(hŒ¹These two maintainers should then receive the message.  If the command does not
return anything, it means the affected file is part of a wider subsystem, so we
should be less specific::”h]”hŒ¸These two maintainers should then receive the message.  If the command does not
return anything, it means the affected file is part of a wider subsystem, so we
should be less specific:”…””}”(hjÉ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h Kfhj|  hžhubj¸  )”}”(hXT  $ ./scripts/get_maintainer.pl --no-l --no-r drivers/example.c
Developer One <dev1@example.com> (maintainer:example subsystem)
Developer Two <dev2@example.org> (maintainer:example subsystem)
Developer Three <dev3@example.com> (maintainer:example subsystem [GENERAL])
Developer Four <dev4@example.org> (maintainer:example subsystem [GENERAL])”h]”hXT  $ ./scripts/get_maintainer.pl --no-l --no-r drivers/example.c
Developer One <dev1@example.com> (maintainer:example subsystem)
Developer Two <dev2@example.org> (maintainer:example subsystem)
Developer Three <dev3@example.com> (maintainer:example subsystem [GENERAL])
Developer Four <dev4@example.org> (maintainer:example subsystem [GENERAL])”…””}”hj×  sbah}”(h]”h ]”h"]”h$]”h&]”jÇ  jÈ  uh1j·  hŸh¯h Kjhj|  hžhubhÆ)”}”(hŒÞHere, picking the first, most specific ones, is sufficient.  When the list is
long, it is possible to produce a comma-delimited e-mail address list on a
single line suitable for use in the To: field of a mailer like this::”h]”hŒÝHere, picking the first, most specific ones, is sufficient.  When the list is
long, it is possible to produce a comma-delimited e-mail address list on a
single line suitable for use in the To: field of a mailer like this:”…””}”(hjå  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h Kphj|  hžhubj¸  )”}”(hŒÎ$ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
  --no-git-fallback --no-substatus --no-rolestats --no-multiline \
  --pattern-depth 1 drivers/example.c
dev1@example.com, dev2@example.org”h]”hŒÎ$ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
  --no-git-fallback --no-substatus --no-rolestats --no-multiline \
  --pattern-depth 1 drivers/example.c
dev1@example.com, dev2@example.org”…””}”hjó  sbah}”(h]”h ]”h"]”h$]”h&]”jÇ  jÈ  uh1j·  hŸh¯h Kthj|  hžhubhÆ)”}”(hŒor this for the wider list::”h]”hŒor this for the wider list:”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h Kyhj|  hžhubj¸  )”}”(hŒà$ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
  --no-git-fallback --no-substatus --no-rolestats --no-multiline \
  drivers/example.c
dev1@example.com, dev2@example.org, dev3@example.com, dev4@example.org”h]”hŒà$ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
  --no-git-fallback --no-substatus --no-rolestats --no-multiline \
  drivers/example.c
dev1@example.com, dev2@example.org, dev3@example.com, dev4@example.org”…””}”hj  sbah}”(h]”h ]”h"]”h$]”h&]”jÇ  jÈ  uh1j·  hŸh¯h K{hj|  hžhubhÆ)”}”(hXc  If at this point you're still facing difficulties spotting the right
maintainers, **and only in this case**, it's possible to send your report to
the Linux kernel security team only.  Your message will be triaged, and you
will receive instructions about whom to contact, if needed.  Your message may
equally be forwarded as-is to the relevant maintainers.”h]”(hŒTIf at this point youâ€™re still facing difficulties spotting the right
maintainers, ”…””}”(hj  hžhhŸNh Nubhï)”}”(hŒ**and only in this case**”h]”hŒand only in this case”…””}”(hj%  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîhj  ubhŒú, itâ€™s possible to send your report to
the Linux kernel security team only.  Your message will be triaged, and you
will receive instructions about whom to contact, if needed.  Your message may
equally be forwarded as-is to the relevant maintainers.”…””}”(hj  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h K€hj|  hžhubeh}”(h]”Œidentifying-contacts”ah ]”h"]”Œidentifying contacts”ah$]”h&]”uh1h°hh²hžhhŸh¯h KFubh±)”}”(hhh]”(h¶)”}”(hŒSending the report”h]”hŒSending the report”…””}”(hjH  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hµhjE  hžhhŸh¯h K‡ubhÆ)”}”(hŒÑReports are to be sent over e-mail exclusively.  Please use a working e-mail
address, preferably the same that you want to appear in ``Reported-by`` tags
if any.  If unsure, send your report to yourself first.”h]”(hŒ…Reports are to be sent over e-mail exclusively.  Please use a working e-mail
address, preferably the same that you want to appear in ”…””}”(hjV  hžhhŸNh Nubj  )”}”(hŒ``Reported-by``”h]”hŒReported-by”…””}”(hj^  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hjV  ubhŒ= tags
if any.  If unsure, send your report to yourself first.”…””}”(hjV  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h K‰hjE  hžhubhÆ)”}”(hXe  The security team and maintainers almost always require additional
information beyond what was initially provided in a report and rely on
active and efficient collaboration with the reporter to perform further
testing (e.g., verifying versions, configuration options, mitigations, or
patches). Before contacting the security team, the reporter must ensure
they are available to explain their findings, engage in discussions, and
run additional tests.  Reports where the reporter does not respond promptly
or cannot effectively discuss their findings may be abandoned if the
communication does not quickly improve.”h]”hXe  The security team and maintainers almost always require additional
information beyond what was initially provided in a report and rely on
active and efficient collaboration with the reporter to perform further
testing (e.g., verifying versions, configuration options, mitigations, or
patches). Before contacting the security team, the reporter must ensure
they are available to explain their findings, engage in discussions, and
run additional tests.  Reports where the reporter does not respond promptly
or cannot effectively discuss their findings may be abandoned if the
communication does not quickly improve.”…””}”(hjv  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h KhjE  hžhubhÆ)”}”(hX  The report must be sent to maintainers, with the security team in ``Cc:``.
The Linux kernel security team can be contacted by email at
<security@kernel.org>.  This is a private list of security officers
who will help verify the bug report and assist developers working on a fix.
It is possible that the security team will bring in extra help from area
maintainers to understand and fix the security vulnerability.”h]”(hŒBThe report must be sent to maintainers, with the security team in ”…””}”(hj„  hžhhŸNh Nubj  )”}”(hŒ``Cc:``”h]”hŒCc:”…””}”(hjŒ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj„  ubhŒ?.
The Linux kernel security team can be contacted by email at
<”…””}”(hj„  hžhhŸNh NubhŒ	reference”“”)”}”(hŒsecurity@kernel.org”h]”hŒsecurity@kernel.org”…””}”(hj   hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”Œmailto:security@kernel.org”uh1jž  hj„  ubhX  >.  This is a private list of security officers
who will help verify the bug report and assist developers working on a fix.
It is possible that the security team will bring in extra help from area
maintainers to understand and fix the security vulnerability.”…””}”(hj„  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h K—hjE  hžhubhÆ)”}”(hX6  Please send **plain text** emails without attachments where possible.
It is much harder to have a context-quoted discussion about a complex
issue if all the details are hidden away in attachments.  Think of it like a
:doc:`regular patch submission <../process/submitting-patches>`
(even if you don't have a patch yet): describe the problem and impact, list
reproduction steps, and follow it with a proposed fix, all in plain text.
Markdown, HTML and RST formatted reports are particularly frowned upon since
they're quite hard to read for humans and encourage to use dedicated viewers,
sometimes online, which by definition is not acceptable for a confidential
security report. Note that some mailers tend to mangle formatting of plain
text by default, please consult Documentation/process/email-clients.rst for
more info.”h]”(hŒPlease send ”…””}”(hjº  hžhhŸNh Nubhï)”}”(hŒ**plain text**”h]”hŒ
plain text”…””}”(hjÂ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîhjº  ubhŒ¿ emails without attachments where possible.
It is much harder to have a context-quoted discussion about a complex
issue if all the details are hidden away in attachments.  Think of it like a
”…””}”(hjº  hžhhŸNh Nubh)”}”(hŒ?:doc:`regular patch submission <../process/submitting-patches>`”h]”hŒinline”“”)”}”(hjÖ  h]”hŒregular patch submission”…””}”(hjÚ  hžhhŸNh Nubah}”(h]”h ]”(Œxref”Œstd”Œstd-doc”eh"]”h$]”h&]”uh1jØ  hjÔ  ubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”Œprocess/security-bugs”Œ	refdomain”jå  Œreftype”Œdoc”Œrefexplicit”ˆŒrefwarn”ˆŒ	reftarget”Œ../process/submitting-patches”uh1hhŸh¯h Kžhjº  ubhX"  
(even if you donâ€™t have a patch yet): describe the problem and impact, list
reproduction steps, and follow it with a proposed fix, all in plain text.
Markdown, HTML and RST formatted reports are particularly frowned upon since
theyâ€™re quite hard to read for humans and encourage to use dedicated viewers,
sometimes online, which by definition is not acceptable for a confidential
security report. Note that some mailers tend to mangle formatting of plain
text by default, please consult Documentation/process/email-clients.rst for
more info.”…””}”(hjº  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h KžhjE  hžhubeh}”(h]”Œsending-the-report”ah ]”h"]”Œsending the report”ah$]”h&]”uh1h°hh²hžhhŸh¯h K‡ubh±)”}”(hhh]”(h¶)”}”(hŒ$Disclosure and embargoed information”h]”hŒ$Disclosure and embargoed information”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hµhj  hžhhŸh¯h K¬ubhÆ)”}”(hŒQThe security list is not a disclosure channel.  For that, see Coordination
below.”h]”hŒQThe security list is not a disclosure channel.  For that, see Coordination
below.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h K®hj  hžhubhÆ)”}”(hŒzOnce a robust fix has been developed, the release process starts.  Fixes
for publicly known bugs are released immediately.”h]”hŒzOnce a robust fix has been developed, the release process starts.  Fixes
for publicly known bugs are released immediately.”…””}”(hj*  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h K±hj  hžhubhÆ)”}”(hX  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
the reporter or an affected party for up to 7 calendar days from the start
of the release process, with an exceptional extension to 14 calendar days
if it is agreed that the criticality of the bug requires more time.  The
only valid reason for deferring the publication of a fix is to accommodate
the logistics of QA and large scale rollouts which require release
coordination.”h]”hX  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
the reporter or an affected party for up to 7 calendar days from the start
of the release process, with an exceptional extension to 14 calendar days
if it is agreed that the criticality of the bug requires more time.  The
only valid reason for deferring the publication of a fix is to accommodate
the logistics of QA and large scale rollouts which require release
coordination.”…””}”(hj8  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h K´hj  hžhubhÆ)”}”(hX|  While embargoed information may be shared with trusted individuals in
order to develop a fix, such information will not be published alongside
the fix or on any other disclosure channel without the permission of the
reporter.  This includes but is not limited to the original bug report
and followup discussions (if any), exploits, CVE information or the
identity of the reporter.”h]”hX|  While embargoed information may be shared with trusted individuals in
order to develop a fix, such information will not be published alongside
the fix or on any other disclosure channel without the permission of the
reporter.  This includes but is not limited to the original bug report
and followup discussions (if any), exploits, CVE information or the
identity of the reporter.”…””}”(hjF  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h K½hj  hžhubhÆ)”}”(hŒíIn other words our only interest is in getting bugs fixed.  All other
information submitted to the security list and any followup discussions
of the report are treated confidentially even after the embargo has been
lifted, in perpetuity.”h]”hŒíIn other words our only interest is in getting bugs fixed.  All other
information submitted to the security list and any followup discussions
of the report are treated confidentially even after the embargo has been
lifted, in perpetuity.”…””}”(hjT  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h KÄhj  hžhubeh}”(h]”Œ$disclosure-and-embargoed-information”ah ]”h"]”Œ$disclosure and embargoed information”ah$]”h&]”uh1h°hh²hžhhŸh¯h K¬ubh±)”}”(hhh]”(h¶)”}”(hŒCoordination with other groups”h]”hŒCoordination with other groups”…””}”(hjm  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hµhjj  hžhhŸh¯h KÊubhÆ)”}”(hXº  While the kernel security team solely focuses on getting bugs fixed,
other groups focus on fixing issues in distros and coordinating
disclosure between operating system vendors.  Coordination is usually
handled by the "linux-distros" mailing list and disclosure by the
public "oss-security" mailing list, both of which are closely related
and presented in the linux-distros wiki:
<https://oss-security.openwall.org/wiki/mailing-lists/distros>”h]”(hX…  While the kernel security team solely focuses on getting bugs fixed,
other groups focus on fixing issues in distros and coordinating
disclosure between operating system vendors.  Coordination is usually
handled by the â€œlinux-distrosâ€ mailing list and disclosure by the
public â€œoss-securityâ€ mailing list, both of which are closely related
and presented in the linux-distros wiki:
<”…””}”(hj{  hžhhŸNh NubjŸ  )”}”(hŒ<https://oss-security.openwall.org/wiki/mailing-lists/distros”h]”hŒ<https://oss-security.openwall.org/wiki/mailing-lists/distros”…””}”(hjƒ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”j…  uh1jž  hj{  ubhŒ>”…””}”(hj{  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h KÌhjj  hžhubhÆ)”}”(hXµ  Please note that the respective policies and rules are different since
the 3 lists pursue different goals.  Coordinating between the kernel
security team and other teams is difficult since for the kernel security
team occasional embargoes (as subject to a maximum allowed number of
days) start from the availability of a fix, while for "linux-distros"
they start from the initial post to the list regardless of the
availability of a fix.”h]”hX¹  Please note that the respective policies and rules are different since
the 3 lists pursue different goals.  Coordinating between the kernel
security team and other teams is difficult since for the kernel security
team occasional embargoes (as subject to a maximum allowed number of
days) start from the availability of a fix, while for â€œlinux-distrosâ€
they start from the initial post to the list regardless of the
availability of a fix.”…””}”(hjœ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h KÔhjj  hžhubhÆ)”}”(hX   As such, the kernel security team strongly recommends that as a reporter
of a potential security issue you DO NOT contact the "linux-distros"
mailing list UNTIL a fix is accepted by the affected code's maintainers
and you have read the distros wiki page above and you fully understand
the requirements that contacting "linux-distros" will impose on you and
the kernel community.  This also means that in general it doesn't make
sense to Cc: both lists at once, except maybe for coordination if and
while an accepted fix has not yet been merged.  In other words, until a
fix is accepted do not Cc: "linux-distros", and after it's merged do not
Cc: the kernel security team.”h]”hX²  As such, the kernel security team strongly recommends that as a reporter
of a potential security issue you DO NOT contact the â€œlinux-distrosâ€
mailing list UNTIL a fix is accepted by the affected codeâ€™s maintainers
and you have read the distros wiki page above and you fully understand
the requirements that contacting â€œlinux-distrosâ€ will impose on you and
the kernel community.  This also means that in general it doesnâ€™t make
sense to Cc: both lists at once, except maybe for coordination if and
while an accepted fix has not yet been merged.  In other words, until a
fix is accepted do not Cc: â€œlinux-distrosâ€, and after itâ€™s merged do not
Cc: the kernel security team.”…””}”(hjª  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h KÜhjj  hžhubeh}”(h]”Œcoordination-with-other-groups”ah ]”h"]”Œcoordination with other groups”ah$]”h&]”uh1h°hh²hžhhŸh¯h KÊubh±)”}”(hhh]”(h¶)”}”(hŒCVE assignment”h]”hŒCVE assignment”…””}”(hjÃ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hµhjÀ  hžhhŸh¯h KèubhÆ)”}”(hXG  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 for a confirmed issue, they can contact the :doc:`kernel CVE
assignment team<../process/cve>` to obtain one.”h]”(hX  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 for a confirmed issue, they can contact the ”…””}”(hjÑ  hžhhŸNh Nubh)”}”(hŒ1:doc:`kernel CVE
assignment team<../process/cve>`”h]”jÙ  )”}”(hjÛ  h]”hŒkernel CVE
assignment team”…””}”(hjÝ  hžhhŸNh Nubah}”(h]”h ]”(jä  Œstd”Œstd-doc”eh"]”h$]”h&]”uh1jØ  hjÙ  ubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”jñ  Œ	refdomain”jç  Œreftype”Œdoc”Œrefexplicit”ˆŒrefwarn”ˆj÷  Œ../process/cve”uh1hhŸh¯h KêhjÑ  ubhŒ to obtain one.”…””}”(hjÑ  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h KêhjÀ  hžhubeh}”(h]”Œcve-assignment”ah ]”h"]”Œcve assignment”ah$]”h&]”uh1h°hh²hžhhŸh¯h Kèubh±)”}”(hhh]”(h¶)”}”(hŒNon-disclosure agreements”h]”hŒNon-disclosure agreements”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hµhj  hžhhŸh¯h KñubhÆ)”}”(hŒpThe Linux kernel security team is not a formal body and therefore unable
to enter any non-disclosure agreements.”h]”hŒpThe Linux kernel security team is not a formal body and therefore unable
to enter any non-disclosure agreements.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhŸh¯h Kóhj  hžhubeh}”(h]”Œnon-disclosure-agreements”ah ]”h"]”Œnon-disclosure agreements”ah$]”h&]”uh1h°hh²hžhhŸh¯h Kñubeh}”(h]”(Œsecurity-bugs”h®eh ]”h"]”(Œsecurity bugs”Œsecuritybugs”eh$]”h&]”uh1h°hhhžhhŸh¯h KŒexpect_referenced_by_name”}”j8  h£sŒexpect_referenced_by_id”}”h®h£subeh}”(h]”h ]”h"]”h$]”h&]”Œsource”h¯uh1hŒcurrent_source”NŒcurrent_line”NŒsettings”Œdocutils.frontend”ŒValues”“”)”}”(hµNŒ	generator”NŒ	datestamp”NŒsource_link”NŒ
source_url”NŒtoc_backlinks”Œentry”Œfootnote_backlinks”KŒsectnum_xform”KŒstrip_comments”NŒstrip_elements_with_classes”NŒstrip_classes”NŒreport_level”KŒ
halt_level”KŒexit_status_level”KŒdebug”NŒwarning_stream”NŒ	traceback”ˆŒinput_encoding”Œ	utf-8-sig”Œinput_encoding_error_handler”Œstrict”Œoutput_encoding”Œutf-8”Œoutput_encoding_error_handler”jb  Œerror_encoding”Œutf-8”Œerror_encoding_error_handler”Œbackslashreplace”Œlanguage_code”Œen”Œrecord_dependencies”NŒconfig”NŒ	id_prefix”hŒauto_id_prefix”Œid”Œdump_settings”NŒdump_internals”NŒdump_transforms”NŒdump_pseudo_xml”NŒexpose_internals”NŒstrict_visitor”NŒ_disable_config”NŒ_source”h¯Œ_destination”NŒ_config_files”]”Œ7/var/lib/git/docbuild/linux/Documentation/docutils.conf”aŒfile_insertion_enabled”ˆŒraw_enabled”KŒline_length_limit”M'Œpep_references”NŒpep_base_url”Œhttps://peps.python.org/”Œpep_file_url_template”Œpep-%04d”Œrfc_references”NŒrfc_base_url”Œ&https://datatracker.ietf.org/doc/html/”Œ	tab_width”KŒtrim_footnote_reference_space”‰Œsyntax_highlight”Œlong”Œsmart_quotes”ˆŒsmartquotes_locales”]”Œcharacter_level_inline_markup”‰Œdoctitle_xform”‰Œdocinfo_xform”KŒsectsubtitle_xform”‰Œimage_loading”Œlink”Œembed_stylesheet”‰Œcloak_email_addresses”ˆŒsection_self_link”‰Œenv”NubŒreporter”NŒindirect_targets”]”Œsubstitution_defs”}”Œsubstitution_names”}”Œrefnames”}”Œrefids”}”h®]”h£asŒnameids”}”(j8  h®j7  j4  jy  jv  jB  j?  j  j  jg  jd  j½  jº  j  j  j/  j,  uŒ	nametypes”}”(j8  ˆj7  ‰jy  ‰jB  ‰j  ‰jg  ‰j½  ‰j  ‰j/  ‰uh}”(h®h²j4  h²jv  hÕj?  j|  j  jE  jd  j  jº  jj  j  jÀ  j,  j  uŒfootnote_refs”}”Œcitation_refs”}”Œautofootnotes”]”Œautofootnote_refs”]”Œsymbol_footnotes”]”Œsymbol_footnote_refs”]”Œ	footnotes”]”Œ	citations”]”Œautofootnote_start”KŒsymbol_footnote_start”K Œ
id_counter”Œcollections”ŒCounter”“”}”…”R”Œparse_messages”]”Œtransform_messages”]”hŒsystem_message”“”)”}”(hhh]”hÆ)”}”(hhh]”hŒ2Hyperlink target "securitybugs" is not referenced.”…””}”hjÌ  sbah}”(h]”h ]”h"]”h$]”h&]”uh1hÅhjÉ  ubah}”(h]”h ]”h"]”h$]”h&]”Œlevel”KŒtype”ŒINFO”Œsource”h¯Œline”Kuh1jÇ  ubaŒtransformer”NŒinclude_log”]”Œ
decoration”Nhžhub.