From nobody Fri Jun 19 07:47:20 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 74B3A15ECCC; Sun, 26 Apr 2026 16:39:56 +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=1777221599; cv=none; b=MiIIj26D7g58yMBS5WGT6gFFqB08skWUbdeIkafTUhxzKwNyt4lVGkWhJw5S7SNElQZXa8vTFhE8Y53IPr3pUM78HQ3K3Nicu+JvZGa5mOKMwDsbQlDUF7Wv4XzoAR9hcCjAO50AsgQCrpkkHg/tmXGgKQ1604xx21RRiTqdsOI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777221599; c=relaxed/simple; bh=Zpm+q72om5yA8p4EnQwGqp0rxQ3IAcd9DhWAGW7hhRQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Mk3JBDFlIVM0JloNVZU7QuplPc4qpejqpJRejr4IG6bqkKgWas60rlq0wOsOW3TJo+8iXdqyapBVMsPgEetgUUhRzgi8TL3dOTkR8YPX08us27IOPIii5af4CWhshk3e9kq4zQJ3oJnikjGZGm1vbHqTfzxvwiwG3F3jGbpGyrw= 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=IbPrCOGu; 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="IbPrCOGu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1777221592; bh=Ud0GtTrott0uPFZMSj7ou7b9Gz9IWwgrKBvjc4zUFoE=; h=From:Message-ID:From; b=IbPrCOGuUHmX+82zwGMIN9EKKrzHc3DAYNUQj94YS1s/5Xh9IOjMQDVstIujHunoO WyeEqWY/kKNqP2cSGLRIofT5xyLxrl0WEvF4uJ44WyBU1ay8e8i0BU1XwfcRJpkMg+ p9MQ5ykDhVROZ0ZzWz2MU9HH3P0NPWQrbKXGVCJw= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 7A609C0B22; Sun, 26 Apr 2026 18:39:52 +0200 (CEST) From: Willy Tarreau To: greg@kroah.com Cc: leon@kernel.org, security@kernel.org, Jonathan Corbet , skhan@linuxfoundation.org, workflows@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Willy Tarreau , Greg KH Subject: [PATCH 1/3] Documentation: security-bugs: do not systematically Cc the security team Date: Sun, 26 Apr 2026 18:39:12 +0200 Message-ID: <20260426163914.19449-2-w@1wt.eu> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260426163914.19449-1-w@1wt.eu> References: <20260426163914.19449-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, to cover the risk of lost messages (spam, vacation etc) but to avoid it for larger teams. Cc: Greg KH Cc: Leon Romanovsky Signed-off-by: Willy Tarreau Acked-by: Greg Kroah-Hartman --- Documentation/process/security-bugs.rst | 26 ++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/Documentation/process/security-bugs.rst b/Documentation/proces= s/security-bugs.rst index 27b028e858610..a8a8fc724e8c8 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -70,11 +70,10 @@ Identifying contacts -------------------- =20 The most effective way to report a security bug is to send it directly to = the -affected subsystem's maintainers and Cc: the Linux kernel 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). +affected subsystem's maintainers. 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 vulnerabi= lity +scanning tool that can be repeated by anyone). =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 @@ -148,12 +147,17 @@ run additional tests. Reports where the reporter doe= s 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 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. -It is possible that the security team will bring in extra help from area -maintainers to understand and fix the security vulnerability. +The report must be sent to maintainers. If there are two or fewer recipie= nts +in your message, and only in this case, you can also Cc: the Linux kernel +security team who will ensure the message is delivered to the proper peopl= e, +and will be able to assist small maintainers teams with a process they are= not +necessarily familiar with. For larger teams, please do not Cc: the Linux +kernel security team, unless you're seeking specific help (e.g. when resen= ding +a message which got no response within a week). The Linux kernel security= team +can be contacted by email at . This is a private lis= t of +security officers who will help verify the bug report and assist developers +working on a fix. It is possible that the security team will bring in ext= ra +help from area maintainers to understand and fix the security vulnerabilit= y. =20 Please send **plain text** emails without attachments where possible. It is much harder to have a context-quoted discussion about a complex --=20 2.52.0 From nobody Fri Jun 19 07:47:20 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 0C22A15ECCC; Sun, 26 Apr 2026 16:47: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=1777222071; cv=none; b=SrzFtYSOnn0RcnLtKthRmGCChnTnLyDiTeFw9OJuNVGdsYLZ9tgym6Gd2zfIVrNS+96ldNw9Npc4eBHKUoBmEkOhleBQ7+yeoqRY+QZPQMJlWR0C6T5GrB03F5HVy96+bsUwkl7PC5L167A6yRc6HSjdPFJKjakZSLKQc8NyeQk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777222071; c=relaxed/simple; bh=ADOdS+wFtSL3i+xPICG/Ewhro69cnkRZlRDLuYLKnhs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=reQYWak35/S8y8D9ygvubVGFoebpUoT2C+x3b4qk8MtnNn5fsIyNBb6phbUo/GadEq924sjsTdi7luurWLYQ2t96VaY18GU1WBQRva8YDFz2T5X862483vA1FU0WeX8TzynQ3plCtboDcxa+xI48JRYJyqc5kTXCFblhN+LuO2Y= 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=oRaoSSSP; 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="oRaoSSSP" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1777221576; bh=YM+ltpPjMBKGJMTdC3V832T2C4ra2+nWzVfbP5aUtKE=; h=From:Message-ID:From; b=oRaoSSSP9wnyHoHrt2ip4dYe6EFg3UdwCpu6o/ztSs7Np1OH8LhJ4X3MYEmwyoWBp USvuBMSjUVQFTw6j4OOCkvsZgrApqEAFhXXhdeOZPDfnl9FeEkCOwnAY+LTWvS7vUq Q/SY7akygeXSavW1/0RgTDLngAvmkPNCBCdfATG4= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 8E8D7C0B0B; Sun, 26 Apr 2026 18:39:36 +0200 (CEST) From: Willy Tarreau To: greg@kroah.com Cc: leon@kernel.org, security@kernel.org, Jonathan Corbet , skhan@linuxfoundation.org, workflows@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Willy Tarreau , Greg KH Subject: [PATCH 2/3] Documentation: security-bugs: explain what is and is not a security bug Date: Sun, 26 Apr 2026 18:39:13 +0200 Message-ID: <20260426163914.19449-3-w@1wt.eu> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260426163914.19449-1-w@1wt.eu> References: <20260426163914.19449-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. Cc: Greg KH Cc: Leon Romanovsky Suggested-by: Leon Romanovsky Signed-off-by: Willy Tarreau --- Leon, while we started this list before our discussion, I reused most of your proposal which was more comprehensive, and merged our initial work into it. I added you in Suggested-by: but I think that Co-developed-by: would be more suitable. If so, for this you'll have to also sign-off the patch. It's as you prefer, I personally don't care. --- Documentation/process/security-bugs.rst | 50 +++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/Documentation/process/security-bugs.rst b/Documentation/proces= s/security-bugs.rst index a8a8fc724e8c8..7cc3a1970ca00 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -66,6 +66,56 @@ 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 to the security team a= re +just regular bugs that have been improperly qualified as security bugs due= to a +misunderstanding of the Linux kernel's threat model, and ought to have been +sent through the normal channels described in +'Documentation/admin-guide/reporting-issues.rst'. + +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. + +In the Linux kernel's threat model, an issue is **not** a security bug, and +should not be reported to the security list, when triggering it requires t= he +reporter to first undermine the system they are attacking. This includes,= but +is not limited to, behavior that only manifests after the administrator has +explicitly enabled it (loading a module, setting a sysctl, writing to a de= bugfs +knob, or otherwise using an interface documented as privileged or unsafe);= bugs +reachable only through root or CAP_SYS_ADMIN or CAP_NET_ADMIN on a machine= the +actor already fully controls, with no further privilege boundary being cro= ssed; +prediction of random numbers that only works in a totally silent environme= nt +(such as IP ID, TCP ports or sequence numbers that can only be guessed in a +lab), issues that appear only in debug, lockdep, KASAN, fault-injection, +CONFIG_NOMMU, or other developer-oriented kernel builds that are not inten= ded +for production use; problems seen only under development simulators, emula= tors, +or fuzzing harnesses that present hardware or input states which cannot oc= cur +on real systems; bugs that require modified or emulated hardware; missing +hardening or defence-in-depth suggestions with no demonstrable exploit path +(including local ASLR bypass); mounting file systems that would be fixed or +rejected by fsck; and bugs in out-of-tree modules or vendor forks, which s= hould +be reported to the relevant vendor. Functional and performance regression= s, +and disagreements with documented kernel policy (for example, "root can lo= ad +modules"), are likewise ordinary bugs or feature requests rather than secu= rity +issues, and should be reported via the usual channels. + +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 --=20 2.52.0 From nobody Fri Jun 19 07:47:20 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 A90A715ECCC; Sun, 26 Apr 2026 16:40:03 +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=1777221605; cv=none; b=GYoaJJoHIESrMJU3R3KVnETDd6fiZNKanQYgwzAtmo6l8ftJ2Fl712f4na9m1gVuNqKg+kMzYZP74ft5DpJ1hdUKZWB+L1dB97pxhSsrxTTv1Dq7PeI8F115ztvbGAk3Y1cyU8FTdpBwHQmXEZwgDh5Ug8y0SuKVCsIk/1fDc1I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777221605; c=relaxed/simple; bh=Dsmk9b6JOZ2COSWcE8v3LewQ7MUJJNOAHhYg5ocMYg4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qYtzUROMEqfFsRIP3P0BsSjfZQ1Kv/n/vdeq+kM3agx03Zwzn+JDo9l2z2J6J7gpi44kJC7I+IOXm8YfdpCTz+Zy6IUMkhDuTmgIH5vgwRBxW5NDjd8ZPAEEOO/IyDcNOQiw9IMREdFfG1z5LIpps13G0jHj+dA83wSA1CQTvs0= 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=VBvNGS7s; 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="VBvNGS7s" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1777221600; bh=WGXZH/Qrm6kjwCpBoY3sQ4uArjnTLotvzkI+PXTq6XU=; h=From:Message-ID:From; b=VBvNGS7sEuEKsAVE7VSgX8OKf+xmrqTaTK7SwCzLnx+EaRvHGoWTWgVYaOHg/Gzx4 boMQYktOaZekge3BiijTp6JYgqW+2gGTZG8Oa5S0mVTMfVtzmW5kRBwHCKwDPBDvec CInH3hlGhn31LP9mJjA4/w7j3IFDFeukJksYxkW0= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 7BC7CC0B22; Sun, 26 Apr 2026 18:40:00 +0200 (CEST) From: Willy Tarreau To: greg@kroah.com Cc: leon@kernel.org, security@kernel.org, Jonathan Corbet , skhan@linuxfoundation.org, workflows@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Willy Tarreau , Greg KH Subject: [PATCH 3/3] Documentation: security-bugs: clarify requirements for AI-assisted reports Date: Sun, 26 Apr 2026 18:39:14 +0200 Message-ID: <20260426163914.19449-4-w@1wt.eu> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260426163914.19449-1-w@1wt.eu> References: <20260426163914.19449-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 Signed-off-by: Willy Tarreau Acked-by: Greg Kroah-Hartman --- Documentation/process/security-bugs.rst | 55 +++++++++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/Documentation/process/security-bugs.rst b/Documentation/proces= s/security-bugs.rst index 7cc3a1970ca00..803d8819694e7 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -180,6 +180,61 @@ 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. + + * **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, obsolte 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