Linux Documentation
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Jonathan Corbet <corbet@lwn.net>
Cc: greg@kroah.com, security@kernel.org, skhan@linuxfoundation.org,
	workflows@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, Willy Tarreau <w@1wt.eu>
Subject: [PATCH 1/5] docs: threat-model: clarify "security bug" vs "vulnerability"
Date: Sun,  2 Aug 2026 22:35:36 +0200	[thread overview]
Message-ID: <20260802203540.3453-2-w@1wt.eu> (raw)
In-Reply-To: <20260802203540.3453-1-w@1wt.eu>

Throwing an LLM (Opus 5) at a file looking for random bugs after having
read the threat model made it ignore certain bugs it found because "the
threat model said they must be ignored". When asked why, the LLM
rightfully reported the ambiguous wording used at a few places:
"is not a security bug", which can also be read as "is not a bug",
despite the rest of the document. That is particularly true when the
LLM decides to look for info using grep.

This change replaces "security bug" with "vulnerability" at a few places
in order to remove this identified ambiguity, and uses "bugs" instead of
issues in two such sentences to insist that what is described remains a
bug.

Cc: Greg KH <greg@kroah.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/threat-model.rst | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/Documentation/process/threat-model.rst b/Documentation/process/threat-model.rst
index 9dd8011dde828..7990673072c4d 100644
--- a/Documentation/process/threat-model.rst
+++ b/Documentation/process/threat-model.rst
@@ -98,11 +98,11 @@ measures whose purpose is to avoid crossing a security boundary when certain
 classes of bugs are found, but a failure of these extra protections do not
 constitute a vulnerability alone.
 
-What does not constitute a security bug
----------------------------------------
+What classes of problems are not considered vulnerabilities
+-----------------------------------------------------------
 
 In the Linux kernel's threat model, the following classes of problems are
-**NOT** considered as Linux Kernel security bugs. However, when it is believed
+**NOT** considered Linux Kernel vulnerabilities. However, when it is believed
 that the kernel could do better, they should be reported, so that they can be
 reviewed and fixed where reasonably possible, but they will be handled as any
 regular bug:
@@ -111,8 +111,8 @@ regular bug:
 
   * outdated kernels and particularly end-of-life branches are out of the scope
     of the kernel's threat model: administrators are responsible for keeping
-    their system up to date. For a bug to qualify as a security bug, it must be
-    demonstrated that it affects actively maintained versions.
+    their system up to date. For a bug to qualify as a vulnerability, it must
+    be demonstrated that it affects actively maintained versions.
 
   * build-level: changes to the kernel configuration that are explicitly
     documented as lowering the security level (e.g. ``CONFIG_NOMMU``), or
@@ -178,7 +178,7 @@ regular bug:
     involving tens of millions of threads, tens of thousands of CPUs,
     unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds).
 
-  * issues whose reproduction requires hardware modification or emulation,
+  * bugs whose reproduction requires hardware modification or emulation,
     including fake USB devices that pretend to be another one.
 
   * as well as issues that can be triggered at a cost that is orders of
@@ -208,17 +208,17 @@ regular bug:
     messages.
 
   * Leaks of kernel memory addresses/pointers do not constitute an immediately
-    exploitable vector and are not security bugs, though they must be reported
-    and fixed.
+    exploitable vector and are not vulnerabilities, though they must be
+    reported and fixed.
 
 * **Crafted file system images**:
 
   * bugs triggered by mounting a corrupted or maliciously crafted file system
-    image are generally not security bugs, as the kernel assumes the underlying
+    image are generally not vulnerabilities, as the kernel assumes the underlying
     storage media is under the administrator's control, unless the filesystem
     driver is specifically documented as being hardened against untrusted media.
 
-  * issues that are resolved, mitigated, or detected by running a filesystem
+  * bugs that are resolved, mitigated, or detected by running a filesystem
     consistency check (fsck) on the image prior to mounting.
 
 * **Physical access**:
@@ -232,4 +232,4 @@ regular bug:
 * **Functional and performance regressions**:
 
   Any issue that can be mitigated by setting proper permissions and limits
-  doesn't qualify as a security bug.
+  doesn't qualify as a vulnerability.
-- 
2.52.0


  reply	other threads:[~2026-08-02 20:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-02 20:35 [PATCH 0/5] docs: improve guidance for AI-assisted bug reports Willy Tarreau
2026-08-02 20:35 ` Willy Tarreau [this message]
2026-08-02 20:35 ` [PATCH 2/5] docs: threat-model: move fake devices out of "non production use" Willy Tarreau
2026-08-02 20:35 ` [PATCH 3/5] docs: security-bugs: clarify what counts as a valid version Willy Tarreau
2026-08-02 20:35 ` [PATCH 4/5] docs: coding-assistant: explain important steps when looking for bugs Willy Tarreau
2026-08-02 20:35 ` [PATCH 5/5] docs: security-bugs: clarify some mandatory steps for AI reports Willy Tarreau
2026-08-03 15:37 ` [PATCH 0/5] docs: improve guidance for AI-assisted bug reports Greg KH
2026-08-03 16:20 ` Jonathan Corbet
2026-08-03 16:24   ` Willy Tarreau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260802203540.3453-2-w@1wt.eu \
    --to=w@1wt.eu \
    --cc=corbet@lwn.net \
    --cc=greg@kroah.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=security@kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox