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,
"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 04/14] docs: threat-model: clarify the case of automatically mounted file systems
Date: Mon, 9 Nov 2026 09:02:30 +0100 [thread overview]
Message-ID: <20261109080240.29444-5-w@1wt.eu> (raw)
In-Reply-To: <20261109080240.29444-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>
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 72cb36dd383d6..b82d5d168b4c3 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 as 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-09 8:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 8:02 [PATCH 00/14] security-bugs doc updates Willy Tarreau
2026-11-09 8:02 ` [PATCH 01/14] docs: security-bugs: reorganize the document without changing its contents Willy Tarreau
2026-11-09 8:02 ` [PATCH 02/14] docs: security-bugs: clarify when to Cc the security team Willy Tarreau
2026-11-09 8:02 ` [PATCH 03/14] docs: security-bugs: never publish reproducers of bugs with a security impact Willy Tarreau
2026-11-09 8:02 ` Willy Tarreau [this message]
2026-11-09 8:02 ` [PATCH 05/14] docs: security-bugs: explain how to send a fix that can be applied Willy Tarreau
2026-11-09 8:02 ` [PATCH 06/14] docs: security-bugs: do not send archives or binary attachments Willy Tarreau
2026-11-09 8:02 ` [PATCH 07/14] docs: security-bugs: first-time reporters must send a single report first Willy Tarreau
2026-11-09 8:02 ` [PATCH 08/14] docs: security-bugs: explain what to do when a report gets no response Willy Tarreau
2026-11-09 8:02 ` [PATCH 09/14] docs: security-bugs: reports left unanswered for 7 days will be dropped Willy Tarreau
2026-11-09 8:02 ` [PATCH 10/14] docs: security-bugs: add a section for maintainers receiving reports Willy Tarreau
2026-11-09 8:02 ` [PATCH 11/14] docs: security-bugs: explain why directly sent reports add extra work Willy Tarreau
2026-11-09 8:02 ` [PATCH 12/14] docs: security-bugs: explain why AI-found bugs are handled publicly Willy Tarreau
2026-11-09 8:02 ` [PATCH 13/14] docs: submitting-patches: defer to security-bugs.rst for security fixes Willy Tarreau
2026-11-09 8:02 ` [PATCH 14/14] docs: netdev: align the security fixes section with security-bugs.rst 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=20261109080240.29444-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=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
all inboxes | Powered by JetHome®