From nobody Sat Jun 13 06:01:41 2026 Received: from mta1.formilux.org (mta1.formilux.org [51.159.59.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3AACD391828; Sat, 9 May 2026 09:49:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=51.159.59.229 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778320149; cv=none; b=JZFKC704yiGsQni+c5tvG20i4I0BPh8o7CDWiR8RAuvxwsIReV81GhwkQHr3fjhcumvT/J7YTtkn2dzQDiMT8X1PK5wuJiLuMM/wGvJGJzAo7KJU9sq4Ene92R3haXfPybavSGX9UF7SWe+jpn3DpYpOwKLxCSyKaRXuESFEEdU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778320149; c=relaxed/simple; bh=PFqviou23ZkO+5tB6xk3/IoTfoOnSRa95kphea5f/2s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HiIDg3SH7aF6weIUJ/m6YDBbXIxK+gb27iIGJDklYhKCNKXeVwaMBNqkBCTjaTWk8tytPD41DYcEHqMo5ctVRxKbgZ04/1wtVuZ2icGHzLyqvK/ptjKjb7ZPPPiK1GewEhEHauIQvWBAhbgYS88jmVrXy1ymmC4gFPFXC06n/F8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu; spf=pass smtp.mailfrom=1wt.eu; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b=RrSQimND; arc=none smtp.client-ip=51.159.59.229 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=1wt.eu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b="RrSQimND" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1778320145; bh=dwMvzj1FWb66GfXWp+Kd9aDgGR46N2xKPDAHX4zwdtU=; h=From:Message-ID:From; b=RrSQimNDsy8UIyqLazDaot8tqmqpd4FL0yXMSegft360x5fksPt4ssKzosUro1kkv lnfEvK1Uz8g1cwYiZWmHBK1wsEwM9eqT7fBUphd7oxhCVSS0SXakOXcTT7d3MmEbyD VpgI7ib0qQ2v3TMVApIGlPK/1lH2g96bTdvusdKA= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 77C67C0A83; Sat, 09 May 2026 11:49:05 +0200 (CEST) From: Willy Tarreau To: greg@kroah.com Cc: Leon Romanovsky , Jonathan Corbet , skhan@linuxfoundation.org, security@kernel.org, workflows@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Willy Tarreau , Greg KH Subject: [PATCH v3 1/3] Documentation: security-bugs: do not systematically Cc the security team Date: Sat, 9 May 2026 11:47:53 +0200 Message-ID: <20260509094755.2838-2-w@1wt.eu> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260509094755.2838-1-w@1wt.eu> References: <20260509094755.2838-1-w@1wt.eu> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" With the increase of automated reports, the security team is dealing with way more messages than really needed. The reporting process works well with most teams so there is no need to systematically involve the security team in reports. Let's suggest to keep it for small lists of recipients and new reporters only. This should continue to cover the risk of lost messages while reducing the volume from prolific reporters. Cc: Greg KH Cc: Leon Romanovsky Reviewed-by: Leon Romanovsky Reviewed-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau --- Documentation/process/security-bugs.rst | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/process/security-bugs.rst b/Documentation/proces= s/security-bugs.rst index 27b028e858610..6dc525858125e 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -148,7 +148,15 @@ run additional tests. Reports where the reporter does= not respond promptly or cannot effectively discuss their findings may be abandoned if the communication does not quickly improve. =20 -The report must be sent to maintainers, with the security team in ``Cc:``. +The report must be sent to maintainers. If there are two or fewer +recipients in your message, you must also always Cc: the Linux kernel +security team who will ensure the message is delivered to the proper +people, and will be able to assist small maintainer teams with processes +they may not be familiar with. For larger teams, Cc: the Linux kernel +security team for your first few reports or when seeking specific help, +such as when resending a message which got no response within a week. +Once you have become comfortable with the process for a few reports, it is +no longer necessary to Cc: the security list when sending to large teams. The Linux kernel security team can be contacted by email at . This is a private list of security officers who will help verify the bug report and assist developers working on a fix. --=20 2.52.0 From nobody Sat Jun 13 06:01:41 2026 Received: from mta1.formilux.org (mta1.formilux.org [51.159.59.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1FCD8379989; Sat, 9 May 2026 09:48:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=51.159.59.229 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778320141; cv=none; b=iCJR+q4jCzVTDlmMJxSHsVfEO3fW8NJ31GutjAAxNoLGRrdq+6YSwxpiesWJtHNBZ3l/EAUWxfrlNK9JekalZurJqM7Dt+heB57YcnAudryk7mfaTK+OuO+9iY4IEW8GhCR4W2DQrYf1rgn81ytevs4cQBqzlbzwkOQka0QmQQk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778320141; c=relaxed/simple; bh=83fqebKEfKr0kM2Ofi4jNsb63LS/xzfGGZK6TJ26oEI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Lx/CEFgdNUyRynviNzGBmtmdNyc58/PL5S1Q5xmmd3qRcV0IX9damlMvGZKtRlpKndV408XrKjXV2Ha5SiIyAzh1k+yV1mwaLVYt9IrylilCeS6DtgCUdy5k7Lz17genfqLfbsLOx/7X+NVAnVAQ0itFLq4sOJ3iaB/BMxDEbqE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu; spf=pass smtp.mailfrom=1wt.eu; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b=TbWOAiF4; arc=none smtp.client-ip=51.159.59.229 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=1wt.eu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b="TbWOAiF4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1778320137; bh=em2Rwq13kbGI0hii+Mft0rDixy2Egs4h+4Nv9nE8Zos=; h=From:Message-ID:From; b=TbWOAiF49g7j1cdBavPIoGH+oaZ9TTNqciO0PDviIadPogCVrnwyKVAJc9mvc6xpb KvnmTGhX9HIFEZpR4YnNQ6eJHFnsgG3qz051+2xcMQhMF7t/bawDuZA0TDK4CQ7rl6 w10dNd7zq7WH4K2HYnOaI42CqNgV8hQeNKmp/pws= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 88F6FC0A83; Sat, 09 May 2026 11:48:57 +0200 (CEST) From: Willy Tarreau To: greg@kroah.com Cc: Leon Romanovsky , Jonathan Corbet , skhan@linuxfoundation.org, security@kernel.org, workflows@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Willy Tarreau , Greg KH Subject: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug Date: Sat, 9 May 2026 11:47:54 +0200 Message-ID: <20260509094755.2838-3-w@1wt.eu> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260509094755.2838-1-w@1wt.eu> References: <20260509094755.2838-1-w@1wt.eu> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The use of automated tools to find bugs in random locations of the kernel induces a raise of security reports even if most of them should just be reported as regular bugs. This patch is an attempt at drawing a line between what qualifies as a security bug and what does not, hoping to improve the situation and ease decision on the reporter's side. It defers the enumeration to a new file, threat-model.rst, that tries to enumerate various classes of issues that are and are not security bugs. This should permit to more easily update this file for various subsystem-specific rules without having to revisit the security bug reporting guide. Cc: Greg KH Cc: Leon Romanovsky Suggested-by: Leon Romanovsky Suggested-by: Greg KH Reviewed-by: Leon Romanovsky Reviewed-by: Shuah Khan Signed-off-by: Willy Tarreau Reviewed-by: Greg Kroah-Hartman --- Documentation/process/index.rst | 1 + Documentation/process/security-bugs.rst | 38 +++- Documentation/process/threat-model.rst | 236 ++++++++++++++++++++++++ 3 files changed, 274 insertions(+), 1 deletion(-) create mode 100644 Documentation/process/threat-model.rst diff --git a/Documentation/process/index.rst b/Documentation/process/index.= rst index dbd6ea16aca70..aa7c959a52b87 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -86,6 +86,7 @@ regressions and security problems. debugging/index handling-regressions security-bugs + threat-model cve embargoed-hardware-issues =20 diff --git a/Documentation/process/security-bugs.rst b/Documentation/proces= s/security-bugs.rst index 6dc525858125e..54260dbfc64d5 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -66,6 +66,42 @@ In addition, the following information are highly desira= ble: the issue appear. It is useful to share them, as they can be helpful to keep end users protected during the time it takes them to apply the fi= x. =20 +What qualifies as a security bug +-------------------------------- + +It is important that most bugs are handled publicly so as to involve the w= idest +possible audience and find the best solution. By nature, bugs that are ha= ndled +in closed discussions between a small set of participants are less likely = to +produce the best possible fix (e.g., risk of missing valid use cases, limi= ted +testing abilities). + +It turns out that the majority of the bugs reported via the security team = are +just regular bugs that have been improperly qualified as security bugs due= to +a lack of awareness of the Linux kernel's threat model, as described in +Documentation/process/threat-model.rst, and ought to have been sent through +the normal channels described in Documentation/admin-guide/reporting-issue= s.rst +instead. + +The security list exists for urgent bugs that grant an attacker a capabili= ty +they are not supposed to have on a correctly configured production system,= and +can be easily exploited, representing an imminent threat to many users. B= efore +reporting, consider whether the issue actually crosses a trust boundary on= such +a system. + +**If you resorted to AI assistance to identify a bug, you must treat it as +public**. While you may have valid reasons to believe it is not, the secur= ity +team's experience shows that bugs discovered this way systematically surfa= ce +simultaneously across multiple researchers, often on the same day. In this +case, do not publicly share a reproducer, as this could cause unintended h= arm; +just mention that one is available and maintainers might ask for it privat= ely +if they need it. + +If you are unsure whether an issue qualifies, err on the side of reporting +privately: the security team would rather triage a borderline report than = miss +a real vulnerability. Reporting ordinary bugs to the security list, howev= er, +does not make them move faster and consumes triage capacity that other rep= orts +need. + Identifying contacts -------------------- =20 @@ -74,7 +110,7 @@ affected subsystem's maintainers and Cc: the Linux kerne= l security team. Do not send it to a public list at this stage, unless you have good reasons to consider the issue as being public or trivial to discover (e.g. result of a widely available automated vulnerability scanning tool that can be repeate= d by -anyone). +anyone, or use of AI-based tools). =20 If you're sending a report for issues affecting multiple parts in the kern= el, even if they're fairly similar issues, please send individual messages (th= ink diff --git a/Documentation/process/threat-model.rst b/Documentation/process= /threat-model.rst new file mode 100644 index 0000000000000..ecb432390e792 --- /dev/null +++ b/Documentation/process/threat-model.rst @@ -0,0 +1,236 @@ +.. _threatmodel: + +The Linux Kernel threat model +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D + +There are a lot of assumptions regarding what the kernel does and does not +protect against. These assumptions tend to cause confusion for bug reports +(:doc:`security-related ones ` vs :doc:`non-security ones +<../admin-guide/reporting-issues>`), and can complicate security enforceme= nt +when the responsibilities for some boundaries is not clear between the ker= nel, +distros, administrators and users. + +This document tries to clarify the responsibilities of the kernel in this +domain. + +The kernel's responsibilities +----------------------------- + +The kernel abstracts access to local hardware resources and to remote syst= ems +in a way that allows multiple local users to get a fair share of the avail= able +resources granted to them, and, when the underlying hardware permits, to a= ssign +a level of confidentiality to their communications and to the data they are +processing or storing. + +The kernel assumes that the underlying hardware behaves according to its +specifications. This includes the integrity of the CPU's instruction set, = the +transparency of the branch prediction unit and the cache units, the consis= tency +of the Memory Management Unit (MMU), the isolation of DMA-capable peripher= als +(e.g., via IOMMU), state transitions in controllers, ranges of values read= from +registers, the respect of documented hardware limitations, etc. + +When hardware fails to maintain its specified isolation (e.g., CPU bugs, +side-channels, hardware response to unexpected inputs), the kernel will us= ually +attempt to implement reasonable mitigations. These are best-effort measures +intended to reduce the attack surface or elevate the cost of an attack wit= hin +the limits of the hardware's facilities; they do not constitute a +kernel-provided safety guarantee. + +Users always perform their activities under the authority of an administra= tor +who is able to grant or deny various types of permissions that may affect = how +users benefit from available resources, or the level of confidentiality of +their activities. Administrators may also delegate all or part of their own +permissions to some users, particularly via capabilities but not only. All= this +is performed via configuration (sysctl, file-system permissions etc). + +The Linux Kernel applies a certain collection of default settings that mat= ch +its threat model. Distros have their own threat model and will come with t= heir +own configuration presets, that the administrator may have to adjust to be= tter +suit their expectations (relax or restrict). + +By default, the Linux Kernel guarantees the following protections when run= ning +on common processors featuring privilege levels and memory management unit= s: + +* **User-based isolation**: an unprivileged user may restrict access to th= eir + own data from other unprivileged users running on the same system. This + includes: + + * stored data, via file system permissions + * in-memory data (pages are not accessible by default to other users) + * process activity (ptrace is not permitted to other users) + * inter-process communication (other users may not observe data exchange= d via + UNIX domain sockets or other IPC mechanisms). + * network communications within the same or with other systems + +* **Capability-based protection**: + + * users not having the ``CAP_SYS_ADMIN`` capability may not alter the + kernel's configuration, memory nor state, change other users' view of = the + file system layout, grant any user capabilities they do not have, nor + affect the system's availability (shutdown, reboot, panic, hang, or ma= king + the system unresponsive via unbounded resource exhaustion). + * users not having the ``CAP_NET_ADMIN`` capability may not alter the ne= twork + configuration, intercept nor spoof network communications from other u= sers + nor systems. + * users not having ``CAP_SYS_PTRACE`` may not observe other users' proce= sses + activities. + +When ``CONFIG_USER_NS`` is set, the kernel also permits unprivileged users= to +create their own user namespace in which they have all capabilities, but w= ith a +number of restrictions (they may not perform actions that have impacts on = the +initial user namespace, such as changing time, loading modules or mounting +block devices). Please refer to ``user_namespaces(7)`` for more details, t= he +possibilities of user namespaces are not covered in this document. + +The kernel also offers a lot of troubleshooting and debugging facilities, = which +can constitute attack vectors when placed in wrong hands. While some of th= em +are designed to be accessible to regular local users with a low risk (e.g. +kernel logs via ``/proc/kmsg``), some would expose enough information to +represent a risk in most places and the decision to expose them is under t= he +administrator's responsibility (perf events, traces), and others are not +designed to be accessed by non-privileged users (e.g. debugfs). Access to = these +facilities by a user who has been explicitly granted permission by an +administrator does not constitute a security breach. + +Bugs that permit to violate the principles above constitute security breac= hes. +However, bugs that permit one violation only once another one was already +achieved are only weaknesses. The kernel applies a number of self-protecti= on +measures whose purpose is to avoid crossing a security boundary when certa= in +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 +--------------------------------------- + +In the Linux kernel's threat model, the following classes of problems are +**NOT** considered as Linux Kernel security bugs. However, when it is beli= eved +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: + +* **Configuration**: + + * outdated kernels and particularly end-of-life branches are out of the = scope + of the kernel's threat model: administrators are responsible for keepi= ng + their system up to date. For a bug to qualify as a security bug, it mu= st 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 + targeted at developers only. + + * OS-level: changes to command line parameters, sysctls, filesystem + permissions, user capabilities, exposure of privileged interfaces, that + explicitly increase exposure by either offering non-default access to + unprivileged users, or reduce the kernel's ability to enforce some + protections or mitigations. Example: write access to procfs or debugfs. + + * issues triggered only when using features intended for development or + debugging (e.g., LOCKDEP, KASAN, FAULT_INJECTION): these features are = known + to introduce overhead and potential instability and are not intended f= or + production use. + + * issues affecting drivers exposed under CONFIG_STAGING, as well as feat= ures + marked EXPERIMENTAL in the configuration. + + * loading of explicitly insecure/broken/staging modules, and generally a= ny + using any subsystem marked as experimental or not intended for product= ion + use. + + * running out-of-tree modules or unofficial kernel forks; these should be + reported to the relevant vendor. + +* **Excess of initial privileges**: + + * actions performed by a user already possessing the privileges required= to + perform that action or modify that state (e.g. ``CAP_SYS_ADMIN``, + ``CAP_NET_ADMIN``, ``CAP_SYS_RAWIO``, ``CAP_SYS_MODULE`` with no furth= er + boundary being crossed). + + * actions performed in user namespace that do not bypass the restrictions + imposed to the initial user (e.g. ptrace usage, signal delivery, resou= rce + usage, access to FS/device/sysctl/memory, network binding, system/netw= ork + configuration etc). + + * anything performed by the root user in the initial namespace (e.g. ker= nel + oops when writing to a privileged device). + +* **Out of production use**: + + This covers theoretical/probabilistic attacks that rely on laboratory + conditions with zero system noise, or those requiring an unrealistic num= ber + of attempts (e.g., billions of trials) that would be detected by standard + system monitoring long before success, such as: + + * prediction of random numbers that only works in a totally silent + environment (such as IP ID, TCP ports or sequence numbers that can onl= y be + guessed in a lab). + + * activity observation and information leaks based on probabilistic + approaches that are prone to measurement noise and not realistically + reproducible on a production system. + + * issues that can only be triggered by heavy attacks (e.g. brute force) = whose + impact on the system makes it unlikely or impossible to remain undetec= ted + before they succeed (e.g. consuming all memory before succeeding). + + * problems seen only under development simulators, emulators, or combina= tions + that do not exist on real systems at the time of reporting (issues + involving tens of millions of threads, tens of thousands of CPUs, + unrealistic CPU frequencies, RAM sizes or disk capacities, network spe= eds. + + * issues 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 key= board + emulator only to retrieve 7 uninitialized bytes in a structure, or + brute-force method involving millions of connection attempts to guess a + port number). + +* **Hardening failures**: + + * ability to bypass some of the kernel's hardening measures with no + demonstrable exploit path (e.g. ASLR bypass, events timing or probing = with + no demonstrable consequence). These are just weaknesses, not + vulnerabilities. + + * missing argument checks and failure to report certain errors with no + immediate consequence. + +* **Random information leaks**: + + This concerns information leaks of small data parts that happen to be th= ere + and that cannot be chosen by the attacker, or face access restrictions: + + * structure padding reported by syscalls or other interfaces. + + * identifiers, partial data, non-terminated strings reported in error + messages. + + * Leaks of kernel memory addresses/pointers do not constitute an immedia= tely + exploitable vector and are not security bugs, though they must be repo= rted + and fixed. + +* **Crafted file system images**: + + * bugs triggered by mounting a corrupted or maliciously crafted file sys= tem + image are generally not security bugs, as the kernel assumes the under= lying + storage media is under the administrator's control, unless the filesys= tem + driver is specifically documented as being hardened against untrusted = media. + + * issues that are resolved, mitigated, or detected by running a filesyst= em + consistency check (fsck) on the image prior to mounting. + +* **Physical access**: + + Issues that require physical access to the machine, hardware modificatio= n, or + the use of specialized hardware (e.g., logic analyzers, DMA-attack tools= over + PCI-E/Thunderbolt) are out of scope unless the system is explicitly + configured with technologies meant to defend against such attacks + (e.g. IOMMU). + +* **Functional and performance regressions**: + + Any issue that can be mitigated by setting proper permissions and limits + doesn't qualify as a security bug. --=20 2.52.0 From nobody Sat Jun 13 06:01:41 2026 Received: from mta1.formilux.org (mta1.formilux.org [51.159.59.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 029D133AD9A; Sat, 9 May 2026 09:48:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=51.159.59.229 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778320127; cv=none; b=A2ewTkbuondVN661UJEzAh5hcNGxPU9VmAAXdXdz1oAiDp+Ve3cXag6RQ05vtiAeT8RJ6236QkKckhG0wjykk/IZkF5abH67XybYA5HJ7O+M6gNt4QET70bQDqyt4K7ornisZaNVqq4mQmPZHw7i7wZD5Xbr5fRbZOV/ueSslDs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778320127; c=relaxed/simple; bh=IuHy3SDaSF/O1aCJXj/7DDXbuuZ10k44yWHhL1/NIOI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iDHbsAsvRbZV13+8Eo0cg6ICNmdZ2SFD/TqPWReV/CNvrekpu+hgPDNFaeeMTiZRr37WEZGlC041nB+BLgVngXgVjI+m5Qpybquh8VRNCaHxZfddP89zRVpgO9fC+xQ9jnmLA571A4ssVr4bK06/x2e/stORKocp8Q9Dgw9LyZk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu; spf=pass smtp.mailfrom=1wt.eu; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b=Pj0nyRL7; arc=none smtp.client-ip=51.159.59.229 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=1wt.eu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b="Pj0nyRL7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1778320121; bh=1351AWjvGF+aSU041y3R7KzOz/KESsLI96cOBC0CfK0=; h=From:Message-ID:From; b=Pj0nyRL78Mqu/8FR5ilGNVDNqAgfGcfzVnjljW23lVsOMW7nvKATzUT97VocHhp3y nf9JTDQnUfhtFFZi/YBidsMSgtTIt4sLs82dOdntmdc7ZtpZ5vvZLKm25UJkapMJtx zFa7dFLUR9Tr6zeJ2TNhFl9v+eCVqg3Q6Wc3b748= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 8D6D9C0A83; Sat, 09 May 2026 11:48:41 +0200 (CEST) From: Willy Tarreau To: greg@kroah.com Cc: Leon Romanovsky , Jonathan Corbet , skhan@linuxfoundation.org, security@kernel.org, workflows@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Willy Tarreau , Greg KH Subject: [PATCH v3 3/3] Documentation: security-bugs: clarify requirements for AI-assisted reports Date: Sat, 9 May 2026 11:47:55 +0200 Message-ID: <20260509094755.2838-4-w@1wt.eu> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260509094755.2838-1-w@1wt.eu> References: <20260509094755.2838-1-w@1wt.eu> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" AI tools are increasingly used to assist in bug discovery. While these tools can identify valid issues, reports that are submitted without manual verification often lack context, contain speculative impact assessments, or include unnecessary formatting. Such reports increase triage effort, waste maintainers' time and may be ignored. Reports where the reporter has verified the issue and the proposed fix typically meet quality standards. This documentation outlines specific requirements for length, formatting, and impact evaluation to reduce the effort needed to deal with these reports. Cc: Greg KH Acked-by: Greg Kroah-Hartman Reviewed-by: Leon Romanovsky Signed-off-by: Willy Tarreau Reviewed-by: Greg Kroah-Hartman --- Documentation/process/security-bugs.rst | 57 +++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/Documentation/process/security-bugs.rst b/Documentation/proces= s/security-bugs.rst index 54260dbfc64d5..f85c65f31f12f 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -167,6 +167,63 @@ the Linux kernel security team only. Your message wil= l be triaged, and you will receive instructions about whom to contact, if needed. Your message = may equally be forwarded as-is to the relevant maintainers. =20 +Responsible use of AI to find bugs +---------------------------------- + +A significant fraction of bug reports submitted to the security team are +actually the result of code reviews assisted by AI tools. While this can b= e an +efficient means to find bugs in rarely explored areas, it causes an overlo= ad on +maintainers, who are sometimes forced to ignore such reports due to their = poor +quality or accuracy. As such, reporters must be particularly cautious abou= t a +number of points which tend to make these reports needlessly difficult to +handle: + + * **Length**: AI-generated reports tend to be excessively long, containi= ng + multiple sections and excessive detail. This makes it difficult to spot + important information such as affected files, versions, and impact. Pl= ease + ensure that a clear summary of the problem and all critical details are + presented first. Do not require triage engineers to scan multiple page= s of + text. Configure your tools to produce concise, human-style reports. + + * **Formatting**: Most AI-generated reports are littered with Markdown t= ags. + These decorations complicate the search for important information and = do + not survive the quoting processes involved in forwarding or replying. + Please **always convert your report to plain text** without any format= ting + decorations before sending it. + + * **Impact Evaluation**: Many AI-generated reports lack an understanding= of + the kernel's threat model and go to great lengths inventing theoretical + consequences. This adds noise and complicates triage. Please stick to + verifiable facts (e.g., "this bug permits any user to gain CAP_NET_ADM= IN") + without enumerating speculative implications. Have your tool read this + documentation as part of the evaluation process. + + * **Reproducer**: AI-based tools are often capable of generating reprodu= cers. + Please always ensure your tool provides one and **test it thoroughly**= . If + the reproducer does not work, or if the tool cannot produce one, the + validity of the report should be seriously questioned. Note that since= the + report will be posted to a public list, the reproducer should only be + shared upon maintainers' request. + + * **Propose a Fix**: Many AI tools are actually better at writing code t= han + evaluating it. Please ask your tool to propose a fix and **test it** b= efore + reporting the problem. If the fix cannot be tested because it relies on + rare hardware or almost extinct network protocols, the issue is likely= not + a security bug. In any case, if a fix is proposed, it must adhere to + Documentation/process/submitting-patches.rst and include a 'Fixes:' tag + designating the commit that introduced the bug. + +Failure to consider these points exposes your report to the risk of being +ignored. + +Use common sense when evaluating the report. If the affected file has not = been +touched for more than one year and is maintained by a single individual, i= t is +likely that usage has declined and exposed users are virtually non-existent +(e.g., drivers for very old hardware, obsolete filesystems). In such cases, +there is no need to consume a maintainer's time with an unimportant report= . If +the issue is clearly trivial and publicly discoverable, you should report = it +directly to the public mailing lists. + Sending the report ------------------ =20 --=20 2.52.0