[BlueZ, v2 0/2] SECURITY: Add top-level security doc

[BlueZ, v2 0/2] SECURITY: Add top-level security doc

[Bastien Nocera]

With reviews from Marco Benatto, Senior Product Security Engineer
at Red Hat.

Changes since v1:
- Added mention of issues that can only happen using vHCI, and not
  real Bluetooth adapters

Bastien Nocera (2):
  SECURITY: Add top-level security doc
  doc: Remove obsolete security-bugs.rst

 SECURITY.md           | 92 +++++++++++++++++++++++++++++++++++++++++++
 doc/security-bugs.rst | 89 -----------------------------------------
 2 files changed, 92 insertions(+), 89 deletions(-)
 create mode 100644 SECURITY.md
 delete mode 100644 doc/security-bugs.rst

-- 
2.55.0

[BlueZ, v2 1/2] SECURITY: Add top-level security doc

[Bastien Nocera]

This will replace the existing documentation written 5 years ago to take
into account the new tools and the new rules around dealing with
security issues.

The new workflow replaces email-based reporting with the GitHub security
advisory tools, explains the CVE ID assignment process, and places strict
limits on the amount of work that can be demanded from BlueZ developers.

It is customary in 2026 to have a top-level SECURITY.md file which
explains the vulnerability workflow.
---
 SECURITY.md | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 SECURITY.md

diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 000000000000..9a2c2daf5c01
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,92 @@
+# Security Policy
+
+## How to Report a Potential Vulnerability?
+
+If you are reporting a not-yet released or urgent issue, please file a draft
+security advisory at
+[https://github.com/bluez/bluez/security/advisories](https://github.com/bluez/bluez/security/advisories),
+containing as many details as possible, including the version affected, and
+any ways to reproduce or fix the problem.
+
+## AI usage
+
+If the vulnerability was found using AI assistance the reporter needs to
+disclose that within the report, also needs to mention which AI was used
+during the processes.
+
+## Embargoed vulnerabilities
+
+All security advisories filed through GitHub will be embargoed until
+either a fix is available in the [main BlueZ repository](https://git.kernel.org/pub/scm/bluetooth/bluez.git/)
+([mirror](https://github.com/bluez/bluez/)), or it has been made public
+by a third-party.
+
+GitHub security advisories have discussion fields, and those discussion fields
+will stay private even after the advisory has been made public. Only trusted
+BlueZ developers will have access to those comments, and unpublished advisories.
+In exceptional circumstances, outside security developers might get access
+to advisories if BlueZ developers find it to be necessary for assessment,
+coordination or publication.
+
+## CVE number assignment
+
+All the vulnerabilities reported through GitHub's security advisories feature
+will be assigned a unique GHSA, which can be used to reference the issue
+externally.
+
+BlueZ maintainers will aim to work with either
+[GitHub](https://docs.github.com/en/code-security/concepts/vulnerability-reporting-and-management/repository-security-advisories#cve-identification-numbers)
+or [Red Hat](https://access.redhat.com/articles/red_hat_cve_program) as CNAs
+to get CVE IDs assigned, on a best effort basis.
+
+Vulnerabilities reported publicly through the linux-bluetooth mailing-list,
+or in any other manner, will not be assigned CVE IDs, and BlueZ maintainers
+will not be working with CNA to get a CVE ID assigned to that vulnerability.
+
+## Disclosure
+
+Once an issue has been discussed privately, accepted as a security issue by
+BlueZ developers, a fix created, and if the severity of the issue is
+high enough (usually only for critical/high), BlueZ developers will aim
+to have distributions forewarned about the issue through the private
+[linux-distros@vs.openwall.org](mailto:linux-distros@vs.openwall.org) mailing-list.
+
+Note that we recommend informing BlueZ developers and working on a fix first,
+before involving the `linux-distros`, as this list has a relatively short
+embargo period which might not allow for much time for the BlueZ developers
+to create and test robust fixes.
+
+We will not be applying any further embargo, or do any restricted disclosure
+for issues that are considered of low or moderate severity.
+
+## Severity assessment
+
+Some Bluetooth functionality is gated behind the `--enable-experimental`
+build option, and behind the `-E/--experimental` command-line option.
+
+When security issues exist in such gated functionality, the security
+level for the issue will be considered as `Low`. This will be done by
+setting the following CVSS fields:
+
+- *Privileges Required*: `High` (requires having an experimental build, and the daemon running as experimental)
+- *Confidentiality*, *Integrity* and *Availability*: `Low`
+
+Reports should take into account the systemd sandboxing features enabled
+in the configuration shipped by BlueZ upstream, if they are applicable
+to the vulnerable portion of the codebase. Issues that only manifest
+themselves when running unsandboxed will have their severity lowered
+as appropriate.
+
+Similarly, Denial-of-Service issues will only be considered as security
+issues if they can be triggered without human intervention, or set up
+on the BlueZ side, otherwise please report those problems as bugs
+using the normal process.
+
+Finally, security issues which are only possible using the root-requiring,
+firmware-stack-and-radio-bypassing vHCI (virtual Bluetooth adapters usually
+used for testing) will not be considered security issues either, just bugs.
+
+## Non-disclosure agreements
+
+The BlueZ developers are not a formal body and therefore unable to enter
+any non-disclosure agreements.
-- 
2.55.0

RE: SECURITY: Add top-level security doc

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1152091

---Test result---

Test Summary:
CheckPatch                    PASS      0.79 seconds
GitLint                       PASS      0.59 seconds
BuildEll                      PASS      20.92 seconds
BluezMake                     PASS      614.40 seconds
MakeCheck                     PASS      18.81 seconds
MakeDistcheck                 PASS      161.68 seconds
CheckValgrind                 PASS      236.79 seconds
CheckSmatch                   PASS      316.47 seconds
bluezmakeextell               PASS      103.26 seconds
IncrementalBuild              PASS      611.30 seconds
ScanBuild                     PASS      990.31 seconds



https://github.com/bluez/bluez/pull/2437

---
Regards,
Linux Bluetooth

[BlueZ, v2 2/2] doc: Remove obsolete security-bugs.rst

[Bastien Nocera]

---
 doc/security-bugs.rst | 89 -------------------------------------------
 1 file changed, 89 deletions(-)
 delete mode 100644 doc/security-bugs.rst

diff --git a/doc/security-bugs.rst b/doc/security-bugs.rst
deleted file mode 100644
index 0dcacfbd9eac..000000000000
--- a/doc/security-bugs.rst
+++ /dev/null
@@ -1,89 +0,0 @@
-=============
-Security bugs
-=============
-
-BlueZ 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.  Please report security bugs to the BlueZ security team.
-
-
-Contact
--------
-
-The BlueZ security team can be contacted by email at <security@bluez.org>.
-This is a private list of security officers who will help verify the bug
-report and develop and release a fix.  If you already have a fix, please
-include it with your report, as that can speed up the process considerably.
-
-As it is with any bug, the more information provided the easier it will
-be to diagnose and fix.  Any exploit code is very helpful and will not
-be released without consent from the reporter unless it has already been
-made public.
-
-Please send plain text emails without attachments where possible.
-
-
-Disclosure and embargoed information
-------------------------------------
-
-The security list is not a disclosure channel.  For that, see Coordination
-below.
-
-Once a robust fix has been developed, the release process starts.  Fixes
-for publicly known bugs are released immediately.
-
-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.
-
-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.
-
-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.
-
-
-Coordination
-------------
-
-Fixes for sensitive bugs, such as those that might lead to privilege
-escalations, may need to be coordinated with the private
-<linux-distros@vs.openwall.org> mailing list so that distribution vendors
-are well prepared to issue a fixed package upon public disclosure of the
-upstream fix.  Distros will need some time to test the proposed patch and
-will generally request at least a few days of embargo, and vendor update
-publication prefers to happen Tuesday through Thursday. When appropriate,
-the security team can assist with this coordination, or the reporter can
-include linux-distros from the start.  In this case, remember to prefix
-the email Subject line with "[vs]" as described in the linux-distros wiki:
-<http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
-
-
-CVE assignment
---------------
-
-The security team does not normally 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 ahead of public disclosure, they will need to contact the private
-linux-distros list, described above. When such a CVE identifier is known
-before a patch is provided, it is desirable to mention it in the commit
-message if the reporter agrees.
-
-
-Non-disclosure agreements
--------------------------
-
-The BlueZ security team is not a formal body and therefore unable to enter
-any non-disclosure agreements.
-- 
2.55.0

Re: [BlueZ, v2 0/2] SECURITY: Add top-level security doc

[patchwork-bot+bluetooth]

Hello:

This series was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Wed, 26 Aug 2026 15:19:04 +0200 you wrote:
> With reviews from Marco Benatto, Senior Product Security Engineer
> at Red Hat.
> 
> Changes since v1:
> - Added mention of issues that can only happen using vHCI, and not
>   real Bluetooth adapters
> 
> [...]

Here is the summary with links:
  - [BlueZ,v2,1/2] SECURITY: Add top-level security doc
    (no matching commit)
  - [BlueZ,v2,2/2] doc: Remove obsolete security-bugs.rst
    https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=e8141342284b

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html