[llvm] Improve description of what is considered a security issue (PR #147035)

Kristof Beyls via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 7 07:48:16 PDT 2025 

https://github.com/kbeyls updated https://github.com/llvm/llvm-project/pull/147035

>From 6428a93b207d1a9bde88c0d1782b11114a998e7f Mon Sep 17 00:00:00 2001
From: Kristof Beyls <kristof.beyls at arm.com>
Date: Fri, 4 Jul 2025 12:27:30 +0200
Subject: [PATCH 1/2] Improve description of what is considered a security
 issue

This patch improves the description of what the LLVM project considers a
security issue, and what not.

This patch is based on the RFC discussion in
https://discourse.llvm.org/t/improving-documentation-of-what-is-considered-a-security-issue-in-llvm/86714
---
 llvm/docs/Security.rst | 59 ++++++++++++++++++++++++++++++------------
 1 file changed, 42 insertions(+), 17 deletions(-)

diff --git a/llvm/docs/Security.rst b/llvm/docs/Security.rst
index 8f04b6594de79..9649b26d445b2 100644
--- a/llvm/docs/Security.rst
+++ b/llvm/docs/Security.rst
@@ -204,6 +204,11 @@ The LLVM Security Policy may be changed by majority vote of the LLVM Security Re
 What is considered a security issue?
 ====================================
 
+Below, with "security-sensitive", we mean that a discovered bug or vulnerability
+that might enable an exploit, may require coordinated disclosure, and therefore
+should be reported to the LLVM Security Response group rather than publishing in
+the public bug tracker.
+
 The LLVM Project has a significant amount of code, and not all of it is
 considered security-sensitive. This is particularly true because LLVM is used in
 a wide variety of circumstances: there are different threat models, untrusted
@@ -217,31 +222,51 @@ security-sensitive). This requires a rationale, and buy-in from the LLVM
 community as for any RFC. In some cases, parts of the codebase could be handled
 as security-sensitive but need significant work to get to the stage where that's
 manageable. The LLVM community will need to decide whether it wants to invest in
-making these parts of the code securable, and maintain these security
-properties over time. In all cases the LLVM Security Response Group should be consulted,
+making these parts of the code securable, and maintain these security properties
+over time. In all cases the LLVM Security Response Group should be consulted,
 since they'll be responding to security issues filed against these parts of the
 codebase.
 
-If you're not sure whether an issue is in-scope for this security process or
-not, err towards assuming that it is. The Security Response Group might agree or disagree
-and will explain its rationale in the report, as well as update this document
-through the above process.
-
 The security-sensitive parts of the LLVM Project currently are the following.
-Note that this list can change over time.
-
-* None are currently defined. Please don't let this stop you from reporting
-  issues to the LLVM Security Response Group that you believe are security-sensitive.
+Note that this list can change over time. If you're not sure whether an issue is
+in-scope for this security process or not, err towards assuming that it is. The
+Security Response Group might agree or disagree and will explain its rationale
+in the report, as well as update this document through the above process.
+
+* Code generation: most miscompilations are not security sensitive. However, a
+  miscompilation where there are clear indications that it can result in the
+  produced binary becoming significantly easier to exploit could be considered
+  security sensitive, and should be reported to the security response group.
+* Run-time libraries: only parts of the run-time libraries are considered
+  security-sensitive. The parts that are not considered security-sensitive are
+  documented below.
 
 The parts of the LLVM Project which are currently treated as non-security
 sensitive are the following. Note that this list can change over time.
 
-* Language front-ends, such as clang, for which a malicious input file can cause
-  undesirable behavior. For example, a maliciously crafted C or Rust source file
-  can cause arbitrary code to execute in LLVM. These parts of LLVM haven't been
-  hardened, and compiling untrusted code usually also includes running utilities
-  such as `make` which can more readily perform malicious things.
-
+* LLVM's language frontends, analyzers, optimizers, and code generators for
+  which a malicious input can cause undesirable behavior. For example, a
+  maliciously crafted C, Rust or bitcode input file can cause arbitrary code
+  to execute in LLVM. These parts of LLVM haven't been hardened, and handling
+  untrusted code usually also includes running utilities such as make which can
+  more readily perform malicious things. For example, vulnerabilities in
+  clang, clangd, or the LLVM optimizer in a JIT caused by untrusted inputs are
+  outside of the scope. We recommend the use of an external sandbox in those
+  cases.
+* The following parts of the run-time libraries are explicitly not considered
+  security-sensitive:
+
+  * parts of the run-time libraries that are not meant to be included in
+    production binaries. For example, most sanitizers are not considered
+    security-sensitive as they are meant to be used during development only, not
+    in production.
+  * for libc and libc++: if a user calls library functionality in an undefined
+    or otherwise incorrect way, this will most likely not be considered a
+    security issue, unless the libc/libc++ documentation explicitly promises to
+    harden or catch that specific undefined behaviour or incorrect usage.
+  * unwinding and exception handling: the implementations are not hardened
+    against malformed or malicious unwind or exception handling data. This is
+    not considered security sensitive.
 
 .. _CVE process: https://cve.mitre.org
 .. _report a vulnerability: https://github.com/llvm/llvm-security-repo/security/advisories/new

>From e6a439e6aa96acbc00a996fa75305bde5e12267e Mon Sep 17 00:00:00 2001
From: Kristof Beyls <kristof.beyls at arm.com>
Date: Mon, 7 Jul 2025 16:46:32 +0200
Subject: [PATCH 2/2] Address review feedback

---
 llvm/docs/Security.rst | 40 +++++++++++++++++++++-------------------
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/llvm/docs/Security.rst b/llvm/docs/Security.rst
index 9649b26d445b2..19fddd51a440d 100644
--- a/llvm/docs/Security.rst
+++ b/llvm/docs/Security.rst
@@ -157,6 +157,7 @@ Members of the LLVM Security Response Group are expected to:
 * Help write and review patches to address security issues.
 * Participate in the member nomination and removal processes.
 
+.. _security-group-discussion-medium:
 
 Discussion Medium
 =================
@@ -204,10 +205,9 @@ The LLVM Security Policy may be changed by majority vote of the LLVM Security Re
 What is considered a security issue?
 ====================================
 
-Below, with "security-sensitive", we mean that a discovered bug or vulnerability
-that might enable an exploit, may require coordinated disclosure, and therefore
-should be reported to the LLVM Security Response group rather than publishing in
-the public bug tracker.
+We define "security-sensitive" to mean that a discovered bug or vulnerability
+may require coordinated disclosure, and therefore should be reported to the LLVM
+Security Response group rather than publishing in the public bug tracker.
 
 The LLVM Project has a significant amount of code, and not all of it is
 considered security-sensitive. This is particularly true because LLVM is used in
@@ -223,15 +223,11 @@ community as for any RFC. In some cases, parts of the codebase could be handled
 as security-sensitive but need significant work to get to the stage where that's
 manageable. The LLVM community will need to decide whether it wants to invest in
 making these parts of the code securable, and maintain these security properties
-over time. In all cases the LLVM Security Response Group should be consulted,
-since they'll be responding to security issues filed against these parts of the
-codebase.
+over time. In all cases the LLVM Security Response Group
+`should be consulted <security-group-discussion-medium_>`__, since they'll be
+responding to security issues filed against these parts of the codebase.
 
-The security-sensitive parts of the LLVM Project currently are the following.
-Note that this list can change over time. If you're not sure whether an issue is
-in-scope for this security process or not, err towards assuming that it is. The
-Security Response Group might agree or disagree and will explain its rationale
-in the report, as well as update this document through the above process.
+The security-sensitive parts of the LLVM Project currently are the following:
 
 * Code generation: most miscompilations are not security sensitive. However, a
   miscompilation where there are clear indications that it can result in the
@@ -241,17 +237,17 @@ in the report, as well as update this document through the above process.
   security-sensitive. The parts that are not considered security-sensitive are
   documented below.
 
-The parts of the LLVM Project which are currently treated as non-security
-sensitive are the following. Note that this list can change over time.
+The following parts of the LLVM Project are currently treated as non-security
+sensitive:
 
 * LLVM's language frontends, analyzers, optimizers, and code generators for
   which a malicious input can cause undesirable behavior. For example, a
-  maliciously crafted C, Rust or bitcode input file can cause arbitrary code
-  to execute in LLVM. These parts of LLVM haven't been hardened, and handling
+  maliciously crafted C, Rust or bitcode input file can cause arbitrary code to
+  execute in LLVM. These parts of LLVM haven't been hardened, and handling
   untrusted code usually also includes running utilities such as make which can
-  more readily perform malicious things. For example, vulnerabilities in
-  clang, clangd, or the LLVM optimizer in a JIT caused by untrusted inputs are
-  outside of the scope. We recommend the use of an external sandbox in those
+  more readily perform malicious things. For example, vulnerabilities in clang,
+  clangd, or the LLVM optimizer in a JIT caused by untrusted inputs are not
+  security-sensitive. We recommend the use of an external sandbox in those
   cases.
 * The following parts of the run-time libraries are explicitly not considered
   security-sensitive:
@@ -268,6 +264,12 @@ sensitive are the following. Note that this list can change over time.
     against malformed or malicious unwind or exception handling data. This is
     not considered security sensitive.
 
+Note that both the explicit security-sensitive and explicit non-security
+sensitive lists can change over time. If you're not sure whether an issue is
+in-scope for this security process or not, err towards assuming that it is. The
+Security Response Group might agree or disagree and will explain its rationale
+in the report, as well as update this document through the above process.
+
 .. _CVE process: https://cve.mitre.org
 .. _report a vulnerability: https://github.com/llvm/llvm-security-repo/security/advisories/new
 .. _llvm/llvm-security-repo: https://github.com/llvm/llvm-security-repo/security

More information about the llvm-commits mailing list