From: Willy Tarreau <w@1wt.eu>
To: Jonathan Corbet <corbet@lwn.net>
Cc: skhan@linuxfoundation.org, Randy Dunlap <rdunlap@infradead.org>,
workflows@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
gregkh@linuxfoundation.org, Johan Hovold <johan@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>
Subject: [PATCH v2 04/14] docs: threat-model: clarify the case of automatically mounted file systems
Date: Sat, 14 Nov 2026 20:00:04 +0100 [thread overview]
Message-ID: <20261114190014.17826-5-w@1wt.eu> (raw)
In-Reply-To: <20261114190014.17826-1-w@1wt.eu>
Bugs triggered by crafted file system images are among the most
frequently reported non-security issues, often with the argument that
some desktop environments automatically mount removable media without
checking them.
Let's state that automatic mounting of unchecked file systems does not
change the analysis: an automounter is expected to check a file system
before mounting it, otherwise it is at fault, and if the check does not
detect the issue, the file system checker is at fault (this doesn't void
the need to handle the kernel side of the report). Fixes should then be
directed to these tools. The only exception remains drivers specifically
documented as being hardened against hostile inputs, as already stated
for non-conforming devices and media.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/process/threat-model.rst | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/threat-model.rst b/Documentation/process/threat-model.rst
index 4c61f196fa84d..a55e7c1c11968 100644
--- a/Documentation/process/threat-model.rst
+++ b/Documentation/process/threat-model.rst
@@ -234,7 +234,12 @@ The following classes of problems are not considered vulnerabilities:
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.
+ consistency check (fsck) on the image prior to mounting. Automatic
+ mounting of unchecked file systems (e.g. removable media mounted by a
+ desktop environment) does not change this: an automounter is expected to
+ check a file system before mounting it, otherwise it is at fault, and if
+ the check does not detect the issue, the file system checker is at fault.
+ In such cases, fixes should be directed to these tools.
* bugs whose reproduction requires hardware modification or emulation,
including fake USB devices that pretend to be another one, or devices
--
2.52.0
next prev parent reply other threads:[~2026-11-14 19:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-14 19:00 [PATCH v2 00/14] security-bugs doc updates Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 01/14] docs: security-bugs: reorganize the document without changing its contents Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 02/14] docs: security-bugs: clarify when to Cc the security team Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 03/14] docs: security-bugs: never publish reproducers of bugs with a security impact Willy Tarreau
2026-11-14 19:00 ` Willy Tarreau [this message]
2026-11-14 19:00 ` [PATCH v2 05/14] docs: security-bugs: explain how to send a fix that can be applied Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 06/14] docs: security-bugs: do not send archives or binary attachments Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 07/14] docs: security-bugs: first-time reporters must send a single report first Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 08/14] docs: security-bugs: explain what to do when a report gets no response Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 09/14] docs: security-bugs: reports left unanswered for 7 days will be dropped Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 10/14] docs: security-bugs: add a section for maintainers receiving reports Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 11/14] docs: security-bugs: explain why directly sent reports add extra work Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 12/14] docs: security-bugs: explain why AI-found bugs are handled publicly Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 13/14] docs: submitting-patches: defer to security-bugs.rst for security fixes Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 14/14] docs: netdev: drop references to the securit list in the doc 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=20261114190014.17826-5-w@1wt.eu \
--to=w@1wt.eu \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=horms@kernel.org \
--cc=johan@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rdunlap@infradead.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