Maintainer workflows discussions
 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 2/5] docs: threat-model: move fake devices out of "non production use"
Date: Sun,  2 Aug 2026 22:35:37 +0200	[thread overview]
Message-ID: <20260802203540.3453-3-w@1wt.eu> (raw)
In-Reply-To: <20260802203540.3453-1-w@1wt.eu>

When originally writing the "fake USB device" entry, it was difficult
to find a suitable section for it and it ended up in "non production
use" but that doesn't fit particularly well. Actually it's very similar
to crafted filesystems, it's a matter of spec violation. Both drivers
and FS are written against a spec, and what the threat model doesn't
cover is out-of-spec use. So let's move the entry there and rename the
crafted FS entry to "Non-conforming devices and media" instead.

Overall it looks more consistent.

The spec was tested agains Qwen3.6-27B-Architect-Polaris2-Fable-B-F451,
Opus-5 and Gemini by reading the threat-model file, then reading a tens
of FS and driver fixes, and they were now all properly classified as
regular bugs, except two that Gemini and Opus rightfully classified as
vulns (Qwen didn't spot the security potential but that's out of our
scope).

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

diff --git a/Documentation/process/threat-model.rst b/Documentation/process/threat-model.rst
index 7990673072c4d..a68be888ce8e5 100644
--- a/Documentation/process/threat-model.rst
+++ b/Documentation/process/threat-model.rst
@@ -178,9 +178,6 @@ regular bug:
     involving tens of millions of threads, tens of thousands of CPUs,
     unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds).
 
-  * 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
     magnitude higher than the expected benefits (e.g. fully functional keyboard
     emulator only to retrieve 7 uninitialized bytes in a structure, or
@@ -211,16 +208,24 @@ regular bug:
     exploitable vector and are not vulnerabilities, though they must be
     reported and fixed.
 
-* **Crafted file system images**:
+* **Non-conforming devices and media**:
 
-  * bugs triggered by mounting a corrupted or maliciously crafted file system
-    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.
+  Drivers are implemented against a specification. When a device or a storage
+  medium violates the specification its driver was written against, the
+  resulting misbehaviour is a regular bug to be fixed, not a vulnerability,
+  unless the driver is specifically documented as being hardened against
+  hostile inputs. The following are therefore not considered vulnerabilities:
 
-  * bugs that are resolved, mitigated, or detected by running a filesystem
+  * bugs triggered by mounting a corrupted or maliciously crafted file system
+    image: mounting a block device is a privileged operation (see above), and
+    the administrator is responsible for the media they mount. This includes
+    issues that are resolved, mitigated, or detected by running a filesystem
     consistency check (fsck) on the image prior to mounting.
 
+  * bugs whose reproduction requires hardware modification or emulation,
+    including fake USB devices that pretend to be another one, or devices
+    reporting values outside their documented ranges.
+
 * **Physical access**:
 
   Issues that require physical access to the machine, hardware modification, or
-- 
2.52.0


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

Thread overview: 6+ 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 ` [PATCH 1/5] docs: threat-model: clarify "security bug" vs "vulnerability" Willy Tarreau
2026-08-02 20:35 ` Willy Tarreau [this message]
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

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-3-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