Re: How to backport (with conflict resolution) CVE-fixing commits to stable releases?

[Quentin Schulz <quentin.schulz@cherry.de>]

Hi Greg,

Thanks for the quick answer!

On 4/14/26 3:52 PM, Greg Kroah-Hartman wrote:
> On Tue, Apr 14, 2026 at 01:40:33PM +0200, Quentin Schulz wrote:
>> Hi all,
>>
>> I would like to backport https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a7ac22d53d0990152b108c3f4fe30df45fcb0181
>> to linux-6.12.y. It is not a conflict-less cherry-pick as many commits have
>> been made to that file between 6.12 and 6.19 when it was fixed, which makes
>> git-cherry-pick conflict. I believe I have a patch that implements the same
>> logic (moving code around, just that that code is different since it was
>> modified after 6.12) in linux-6.12.y that does the original commit in 6.19.
> 
> Then backport all of the needed fixes, that's the simplest way, just
> send a series of patches.
> 

The conflicts are introduced by commits which aren't fixes, and they 
also aren't matching rules for acceptance into the -stable tree 
(according to 
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#everything-you-ever-wanted-to-know-about-linux-stable-releases), 
so it's not *that* easy. (But I now know what to do having read your 
answer below and a few commit messages in linux-6.12.y).

>> My understanding is that this means this patch fits Option 3: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-3.
>>
>> 1) It is not specified there what to do with git trailer tags, e.g.
>> Reviewed-by, Acked-by, Tested-by. I'm assuming https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
> 
> You keep them as-is.
> 
> See the many backports that are sent to the stable@vger.kernel.org list
> for many examples of this.
> 

Thanks for the clarification.

It seemed weird to me to have Reviewed-by, Tested-by, Acked-by and 
Signed-off-by (used in the patch's delivery path of the original commit) 
kept, as the code isn't the same (and since based on a different kernel 
version, untested by the original patch's tester(s)) and conflicts (IMO) 
with the rule given in 
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes 
("if the patch has changed substantially in following version, these 
tags might not be applicable anymore and thus should be removed").
Maybe I'm reading too much into this and it's clear for most people what 
to do from the docs? Or is this something we would like to improve in 
the docs? Just trying to make the process clearer (well, to me at least) 
in the docs now that you've cleared up what's expected.

[...]

>> 3) Finally, the last question I have is whether it's required/recommended,
>> and if so, how, to tell maintainers of
>> https://git.kernel.org/pub/scm/linux/security/vulns.git that this patch is
>> for CVE X, in my case https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published/2026/CVE-2026-22986.dyad.
>> Maybe their tooling will automatically pick it up once merged, but I
>> couldn't find documentation either in
> 
> Maintainers, and stable backports, don't care about CVEs, keep the
> wording in the changelog identical and properly mark what the commit id
> is that you are backporting.  Again, there are many thousands of
> examples on the stable mailing list if you want to look in the archives.
> 

I was rather trying to ask if there is a separate process from the 
backporting of the patch to make sure vulns.git would be updated 
accordingly, and make vulns.git maintainers' life easier.

> By keeping the original git id, the CVE scripts will properly pick this
> up when a commit that has been assigned to a CVE in the past is
> backported to older kernels, and then the json records will be
> automatically updated when the release happens, and pushed out to
> cve.org.  There's nothing special you need to do here at all.
> 

Which you answered here, thanks! Is this (nothing to do but follow the 
"you must note the upstream commit ID in the changelog of your 
submission with a separate line above the commit text, like this" rule 
and everything will automagically be eventually updated) something 
expected to be part of common knowledge or do we want this documented on 
kernel.org/docs? If the latter, should that rather be part of 
Documentation/process/cve.rst, or 
Documentation/process/stable-kernel-rules.rst, or both, and/or in 
vulns.git's main README, or something else?

> Hope this helps,
> 

It did! Now trying to figure out if the docs can be improved to reflect 
what I learned here.

I'll send my (code) patch for stable soon and monitor this thread here 
if there's something I could work on for the docs.

Cheers,
Quentin