From nobody Fri Oct 2 10:07:45 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 C046E2F1FED; Sun, 2 Aug 2026 20:36:11 +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=1785702973; cv=none; b=O2sMbgL8DsZPazqHp8fpbI843V27KidApngzXneAOyiHt+ypT1dhaJ3iRAbmYtGaWsHh2C5SqPIDN8U2jmqlG83ehlyBUTXpkNJnJrRj5TdzvkLdsi0I5tmSn7m/Me8dgr7bAH9NhXo77JMn8ir2wqH/YCmkw7SmDbMyL6WkMMQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785702973; c=relaxed/simple; bh=RZmSeyhINOhhNMmUfcRtVvWUHP4Gdyb71lWg3sMFaxM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Iuenq5BjuJ5NKyPAXY0eg3v7gWgYry/y4wu1C3GaT1dbN+VIxqMfHAzOqvvppbRGWKUvjsr/Hmthz1T8vKSwe0g1p5U//jRVB2ets6/rRpdhZAzJwiJAoR7Vxqx7WzcPc23UZ9uEIt3TsV3lEEHsbFAtOuBQRFe/30sNGZVoKCg= 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=n7bFtj1s; 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="n7bFtj1s" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1785702970; bh=F3T2dBngo+BI+KTE+Nrfru/ocuzRAXRpjgzzSULYQpU=; h=From:Message-ID:From; b=n7bFtj1s66aJTdQpIqChJPQNHR5Ybkt04XIvMlBFd0WFeqdLPAWtFqPkC0YeJPPq5 ZZ1JZ+KIJ2odCuekf92vELZRqIO+zHhwfNX27ZiffDa5N2rcEOw4iCnvKfjImMfgl0 QedAWWg89Wkz5taHGcjR4ZWsxwuoZ+kVBOUA7UUk= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 1A8BEC0A7D; Sun, 02 Aug 2026 22:36:10 +0200 (CEST) From: Willy Tarreau To: Jonathan Corbet 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 Subject: [PATCH 1/5] docs: threat-model: clarify "security bug" vs "vulnerability" Date: Sun, 2 Aug 2026 22:35:36 +0200 Message-ID: <20260802203540.3453-2-w@1wt.eu> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260802203540.3453-1-w@1wt.eu> References: <20260802203540.3453-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" Throwing an LLM (Opus 5) at a file looking for random bugs after having read the threat model made it ignore certain bugs it found because "the threat model said they must be ignored". When asked why, the LLM rightfully reported the ambiguous wording used at a few places: "is not a security bug", which can also be read as "is not a bug", despite the rest of the document. That is particularly true when the LLM decides to look for info using grep. This change replaces "security bug" with "vulnerability" at a few places in order to remove this identified ambiguity, and uses "bugs" instead of issues in two such sentences to insist that what is described remains a bug. Cc: Greg KH Signed-off-by: Willy Tarreau --- Documentation/process/threat-model.rst | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/Documentation/process/threat-model.rst b/Documentation/process= /threat-model.rst index 9dd8011dde828..7990673072c4d 100644 --- a/Documentation/process/threat-model.rst +++ b/Documentation/process/threat-model.rst @@ -98,11 +98,11 @@ measures whose purpose is to avoid crossing a security = boundary when certain classes of bugs are found, but a failure of these extra protections do not constitute a vulnerability alone. =20 -What does not constitute a security bug ---------------------------------------- +What classes of problems are not considered vulnerabilities +----------------------------------------------------------- =20 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 +**NOT** considered Linux Kernel vulnerabilities. However, when it is belie= ved 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: @@ -111,8 +111,8 @@ regular bug: =20 * 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. + their system up to date. For a bug to qualify as a vulnerability, it m= ust + be demonstrated that it affects actively maintained versions. =20 * build-level: changes to the kernel configuration that are explicitly documented as lowering the security level (e.g. ``CONFIG_NOMMU``), or @@ -178,7 +178,7 @@ regular bug: involving tens of millions of threads, tens of thousands of CPUs, unrealistic CPU frequencies, RAM sizes or disk capacities, network spe= eds). =20 - * issues whose reproduction requires hardware modification or emulation, + * bugs whose reproduction requires hardware modification or emulation, including fake USB devices that pretend to be another one. =20 * as well as issues that can be triggered at a cost that is orders of @@ -208,17 +208,17 @@ regular bug: messages. =20 * 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. + exploitable vector and are not vulnerabilities, though they must be + reported and fixed. =20 * **Crafted file system images**: =20 * 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 + image are generally not vulnerabilities, as the kernel assumes the und= erlying storage media is under the administrator's control, unless the filesys= tem driver is specifically documented as being hardened against untrusted = media. =20 - * issues that are resolved, mitigated, or detected by running a filesyst= em + * bugs that are resolved, mitigated, or detected by running a filesystem consistency check (fsck) on the image prior to mounting. =20 * **Physical access**: @@ -232,4 +232,4 @@ regular bug: * **Functional and performance regressions**: =20 Any issue that can be mitigated by setting proper permissions and limits - doesn't qualify as a security bug. + doesn't qualify as a vulnerability. --=20 2.52.0 From nobody Fri Oct 2 10:07:45 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 0E780262FD0; Sun, 2 Aug 2026 20:36:01 +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=1785702965; cv=none; b=lB1UAhQWjxlv7JXow3RiUe8KaP2N9NNAO/9kKZQYuQoQ5za+Z99/8ri6O0FOOkDo2Ks9uKxTCP24rtJwiKK/JM3uAT5nSPuJPzPs13wYtjQNmWjkiLF9TNXU1iYUOwHe71IVRMmrQdpcp8P3eE2TzHIvNcRVXUAc9rZOx0JaEeU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785702965; c=relaxed/simple; bh=EHX/hYZuxJtFRViQGR1BVK9xjcEFlgU64cDINJfXNUw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lJG0VFjHiRzGHqsr5bAQJQbIOSAjzSIyEiD7XNV3ScvCx5gn333zGVSrAFqZcEiCuTTdFMRfoHmTtpsj+4IsoxVu8Isau5Di8a2y+m6rH384ZlgLfqLyk7FDsiKZmxQacAwGzi6V5hWtVz1NG69KJZC41cMgRqyJuw6iuSWO7xg= 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=Hg7Wlf1l; 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="Hg7Wlf1l" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1785702954; bh=vgYXVd1EBLSMzmWdcjabI0y7ehgg63R55qFZhgRRAYg=; h=From:Message-ID:From; b=Hg7Wlf1lo5DBm0le//6UI5rwu12ftsUgRI9HSUBgWHTPu903pho49tI38TelogJI0 gzUi9IjDnvpL9o7o71LzlNU2RFIdI56gxjCJTZRojHKFebXCZcahx5DcTdqC8RcVNl nHGgGmK1b6qBsvRJAqt4o4IPaXN5Uzqv1Bk3qLt0= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 3CF66C0A7D; Sun, 02 Aug 2026 22:35:54 +0200 (CEST) From: Willy Tarreau To: Jonathan Corbet 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 Subject: [PATCH 2/5] docs: threat-model: move fake devices out of "non production use" Date: Sun, 2 Aug 2026 22:35:37 +0200 Message-ID: <20260802203540.3453-3-w@1wt.eu> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260802203540.3453-1-w@1wt.eu> References: <20260802203540.3453-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" 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 Signed-off-by: Willy Tarreau --- 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 spe= eds). =20 - * 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 key= board 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. =20 -* **Crafted file system images**: +* **Non-conforming devices and media**: =20 - * bugs triggered by mounting a corrupted or maliciously crafted file sys= tem - image are generally not vulnerabilities, as the kernel assumes the und= erlying - storage media is under the administrator's control, unless the filesys= tem - driver is specifically documented as being hardened against untrusted = media. + Drivers are implemented against a specification. When a device or a stor= age + 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 vulnerabiliti= es: =20 - * bugs that are resolved, mitigated, or detected by running a filesystem + * bugs triggered by mounting a corrupted or maliciously crafted file sys= tem + image: mounting a block device is a privileged operation (see above), = and + the administrator is responsible for the media they mount. This includ= es + issues that are resolved, mitigated, or detected by running a filesyst= em consistency check (fsck) on the image prior to mounting. =20 + * 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**: =20 Issues that require physical access to the machine, hardware modificatio= n, or --=20 2.52.0 From nobody Fri Oct 2 10:07:45 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 09DB42F1FED; Sun, 2 Aug 2026 20:36:19 +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=1785702981; cv=none; b=BhoeEb368q9axjhibo6IVfqOkvSAa7IJ1rcWECTLF0M5dZBjTmhcx1W3D0EwP/ZIWgo/G08JgXdz7/4cQULU3nCXhnXj51YbqnM1AUuMtAymNiBwt7kAZ0zfFyAn8TbJmCsOgdIkwzsn1b4LirkGIiCPWznyFKlo7fCBLAn/cbM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785702981; c=relaxed/simple; bh=/ax0l9rScBedUQ4ArUTep6Na7Q3QRH0wX20HyIGC1x8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=q6buzXpkzJvLbS9MMrmbVvPmpuDh2GQSyy49D0JJFd9WiGmXooIM/6tBx6byr43HmH323AAWpOGaHwSEvFqs8WXfVXCjIinxlCiuchHVc7nyABoTrjQmERpo/ROP21zXGGFVhqV9wSKhXPATiWobP2OGCpqW7elPa90VBFlMSvM= 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=V5ZeIQFm; 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="V5ZeIQFm" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1785702978; bh=EP2E+BcQxM46wRN+1R6UApkJ5/0ihgYvp/H+1ZpDISY=; h=From:Message-ID:From; b=V5ZeIQFmBXojW8hnEMAWF9D4hRJornrUUBqcW6njddbBwD1uoajudSKOZcgJa2TkQ k1ov8mYKl1snw4Xo8Dffa4ZriOndxhZJU7QAXru9GMxKFXIwUdb6S36nW2w1KueKIB Qt4V+h1D+Rls9aFJiXBAFkHEBVYXaGFP3SyWBnnQ= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 1A0FCC0A7D; Sun, 02 Aug 2026 22:36:18 +0200 (CEST) From: Willy Tarreau To: Jonathan Corbet 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 Subject: [PATCH 3/5] docs: security-bugs: clarify what counts as a valid version Date: Sun, 2 Aug 2026 22:35:38 +0200 Message-ID: <20260802203540.3453-4-w@1wt.eu> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260802203540.3453-1-w@1wt.eu> References: <20260802203540.3453-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" Too often we're getting reports saying "still valid in latest mainline" with no indication of when this was verified, making this indication pointless. Let's clarify it and insist on having a version or commit ID, and that the version must necessarily be for a kernel.org kernel and not a distro one. Cc: Greg KH Signed-off-by: Willy Tarreau --- Documentation/process/security-bugs.rst | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Documentation/process/security-bugs.rst b/Documentation/proces= s/security-bugs.rst index 3c51ddde31dd9..6f7c21515e9ea 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -18,6 +18,10 @@ information is helpful. The following information are a= bsolutely necessary in **any** security bug report: =20 * **affected kernel version range**: with no version indication, your re= port + will not be processed. Note that a time-dependent version such as "la= test + mainline" is not acceptable. A stable identifier such as a commit ID = or an + exact version is required. Versions designating kernels not coming fr= om + kernel.org (such as distro kernels) are meaningless to maintainers and will not be processed. A significant part of reports are for bugs that have already been fixed, so it is extremely important that vulnerabili= ties are verified on recent versions (development tree or latest stable --=20 2.52.0 From nobody Fri Oct 2 10:07:45 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 D5F42337107; Sun, 2 Aug 2026 20:36:27 +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=1785702989; cv=none; b=bGVQGnt45JlHhm9l/Rd6lSr6IlW9r6wDeiu6+s3QKalAe7DH/qPatcvn62HttGrWUB2ZzAvrAmnIWTzFNaLxNsgiy2EWjiOdMcVJ6vPhulZJ83Zc8T/Ru4j1gR0uyuKoRrm9FewGrTfE2dLtVuFdFTRYWmEp8y+Z6MbvqcLP9iw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785702989; c=relaxed/simple; bh=1x4tpxFTAiH+je9cZG1X7qLnucoHC85fBVgo/sqgzAE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=F+0fK7Xd3xjrLZeOIq3LVr/TVoLGu2ve3jkC6T557Ju35dapoM3LFUUs3ySjdGhdbnDb3idF6LMBgcnZEHMXT3F+a0ZogCgnOff0Xqw79Jke5ViubP1XnMSzFBeEr/pmvgJq2fGiWiWIdypBW6vRQaHaCLPb8Gvy3/hPh0V0ZnU= 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=LPX2vwQd; 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="LPX2vwQd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1785702986; bh=PvfLxAdxMT3vY2Re951yKjeKaKCuN9M/jVDlLgztJAk=; h=From:Message-ID:From; b=LPX2vwQdV2IkoPhrJAtdgufXGUf3F0jpDDL8q9W0dkp7z4pVMkGwi2FFNWE1zdh5z /63PivO65FszsbkgDPAg/PFH1arCW0RPcNXCh9gcMB1jUG5wHeN8nhQhftUpE9b7SS ykumd+bsV1nriKz9s+6/gMCCRF9sGZPUH8kSXsJk= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 1ACCAC0A7D; Sun, 02 Aug 2026 22:36:26 +0200 (CEST) From: Willy Tarreau To: Jonathan Corbet 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 Subject: [PATCH 4/5] docs: coding-assistant: explain important steps when looking for bugs Date: Sun, 2 Aug 2026 22:35:39 +0200 Message-ID: <20260802203540.3453-5-w@1wt.eu> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260802203540.3453-1-w@1wt.eu> References: <20260802203540.3453-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" Due to the increasing capabilities of available AI models, it's becoming common to see them used to find bugs anywhere. Unfortunately the quality of reports (especially when they're believed to be security relevant) is still lacking a lot. Let's add a section dedicated to bug finding, explaining the few mandatory steps (noting commit ID, writing the fix from the session that found the bug, building and testing, etc). This was tested both against Qwen3.6-27B-Architect-Polaris2-Fable-B-F451 running under Hermes, and Opus-5, and both followed the instructions to the letter, verifying their results and checking threat-model.rst to decline the vulnerability aspect. At least in the current form it's expected to improve the situation a little bit. Cc: Greg KH Signed-off-by: Willy Tarreau --- Documentation/process/coding-assistants.rst | 37 +++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/Documentation/process/coding-assistants.rst b/Documentation/pr= ocess/coding-assistants.rst index 899f4459c52d2..e71df7d28467e 100644 --- a/Documentation/process/coding-assistants.rst +++ b/Documentation/process/coding-assistants.rst @@ -57,3 +57,40 @@ Basic development tools (git, gcc, make, editors) should= not be listed. Example:: =20 Assisted-by: Claude:claude-3-opus coccinelle sparse + +Procedure for finding and fixing bugs +=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=3D=3D=3D=3D=3D=3D=3D=3D + +When an AI assistant is used to find and fix bugs, it **MUST** follow at l= east +these steps: + +1. Before starting, read the whole process documentation listed above, as = well + as any other document mentioned in the request. Do not rely on isolated + parts found by keyword search. +2. Note the commit ID and Locate a bug as instructed. +3. For any bug found that is not trivial, verify that it looks real by + attempting to create a reproducer to demonstrate it. Lacking it may cau= se + the report to be ignored, as many unverified bug reports sent to mainta= iners + happen to be invalid. Stop here if it finally looks wrong. +4. Write a fix for the bug. This part is not optional: except in a few very + rare cases, an AI assistant able to find a bug is able to fix it. Note = that + fixes written in the same session as used to find the bug will generally + lead to better and more accurate fixes as the LLM's reasoning context + remains present. +5. Build and verify that the fix works either using the reproducer or by + re-running a complete analysis; drop any fix that doesn't work and try + another one. The fix must not add build warnings and must pass the + checkpatch.pl checks (see submitting-patches.rst). +6. Commit the working fix with a detailed message describing the problem, = the + solution and a Fixes tag. Do not add a Signed-off-by tag, and add an + Assisted-by tag, as described above. +7. Identify the maintainers and lists using scripts/get_maintainer.pl. + Documentation/process/security-bugs.rst shows how to do that. +8. Indicate what could not be done. If the fix could not be built or teste= d, or + if no reproducer could be produced, say so explicitly: maintainers curr= ently + waste too much time analyzing unverified reports and untested fixes. +9. Read Documentation/process/threat-model.rst to determine whether the bu= g is + a vulnerability or a regular bug, and leave the result to the reporter = for + review (the assistant must never send anything itself). Regular bugs are + submitted as described in Documentation/process/submitting-patches.rst, + vulnerabilities as described in Documentation/process/security-bugs.rst. --=20 2.52.0 From nobody Fri Oct 2 10:07:45 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 ED4A232E6B4; Sun, 2 Aug 2026 20:36:35 +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=1785702997; cv=none; b=IWD7VWnUda/IaldiFU/ih0C/C1mL5ZIhEJr0HkucyZ69/ZFVCfv/GIR0GLVrit/22O+3og98WhkQqFh3JOeAUPgOedmlSu4iLV1qj7NTzGhaoHEzFtMIfzjtse5rLStkU51o9FaoJyyiXqDL6Y8gAx4FJz+NB2+zaxaCkPMVtho= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785702997; c=relaxed/simple; bh=civuMLuOfvRxGC/7AMGzlxoLMrrD/qXjD5Glt6SQlC0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=J+82zxa6K8HiUS6014xhCSDl17FKRH8HpcX7G9zREdhVquH9+OJTrKuGPnMJXPzjHUtA1z4fwrskseKgd191NDGCym51fHi4EU6T+UrXJvA6dgNFa8sOKNCuOCoXl9Jxhbp/bwqzqIA8NRBVPtN1IRZTRmrobXHz8ngeLPlx3vA= 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=fI9wXiZl; 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="fI9wXiZl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1785702994; bh=Il8upSbhflz90D/cHN3ACePK3pJEfC3UUul8QIo+Iqs=; h=From:Message-ID:From; b=fI9wXiZln3uXDd9Z/ItVPZjnRwBhdDQCmOhZfhz0RYecsqCK5jF03MsRSSlL5zIkB P5aNLn5mif14dA4FY2iSlFwmOX+Gdr1shHb4tPKVRDzidze36EcHx/yzKG6qqkxcqg jGcotuZ/B0wNcfBc/7iW7TKYXF6Y2co9jIsiKNcg= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 202A9C0A7D; Sun, 02 Aug 2026 22:36:34 +0200 (CEST) From: Willy Tarreau To: Jonathan Corbet 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 , Chris Mason Subject: [PATCH 5/5] docs: security-bugs: clarify some mandatory steps for AI reports Date: Sun, 2 Aug 2026 22:35:40 +0200 Message-ID: <20260802203540.3453-6-w@1wt.eu> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260802203540.3453-1-w@1wt.eu> References: <20260802203540.3453-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 security team is still seeing a lot of reports lacking a full patch and showing missing contents and formatting issues. Since AI assistants tend to be better than humans at following instructions, let's defer to coding-assistants.rst to follow mandatory steps, and insist on the plain text format, as well as asking for recipient addresses and an e-mail client setup hint to be mentioned early in the report for the reporter. Also add a link to https://github.com/masoncl/kres.git which contains way more advanced and detailed steps for those willing to go further. Tested with Opus-5 and Qwen3.6-27B-Architect-Polaris2-Fable-B-F451, both of which proceeded according to instructions. Cc: Greg KH Cc: Chris Mason Signed-off-by: Willy Tarreau --- Documentation/process/security-bugs.rst | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/Documentation/process/security-bugs.rst b/Documentation/proces= s/security-bugs.rst index 6f7c21515e9ea..c7dfecc87764c 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -229,6 +229,28 @@ there is no need to consume a maintainer's time with a= n unimportant report. If the issue is clearly trivial and publicly discoverable, you should report = it directly to the public mailing lists. =20 +At the very least, when using an AI assistant to find and report bugs, mak= e the +assistant read this file and threat-model.rst before proceeding, and have = it +follow the procedure described in coding-assistants.rst: work on an up-to-= date +mainline tree and note the commit ID, verify the bug is real, write a fix, +build it warning-free and checkpatch-clean, commit it with a Fixes tag, and +identify the maintainers with get_maintainer.pl. + +On top of that procedure, the AI assistant **MUST**: + +1. Prepare a plain-text report explaining the problem. It must contain the + four items listed at the top of this file as absolutely necessary: the + affected version or commit ID noted while following the procedure above, + the description of the problem, the reproducer or its status, and the + triggering conditions. +2. Start the report with a temporary section listing the recipients' addre= sses + (maintainers+list for the patch, maintainers only for the report and + reproducer), and with instructions reminding the reporter to check that + their email client is properly setup (see email-clients.rst), and leave= it + to the reporter to remove that temporary section. + +A more detailed process is covered at https://github.com/masoncl/kres.git. + Sending the report ------------------ =20 --=20 2.52.0