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

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

[Quentin Schulz]

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.

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

"""
However if the patch has changed substantially in following version, 
these tags might not be applicable anymore and thus should be removed. 
Usually removal of someone’s Acked-by, Tested-by or Reviewed-by tags 
should be mentioned in the patch changelog with an explanation (after 
the ‘---’ separator).
"""

applies here but I think it should be made explicit in 
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-3. 
Did I understand this correctly? Could we specify in 
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-3 
what to do with those tags? Also should the people whose tags are 
removed be added in Cc of the backport patch (they won't be 
automatically with git-send-email anymore since their tags are removed)?

2) I'm also wondering if we should strip the Signed-off-by tags used in 
the original patch's delivery path to Linus. After all, it'll go through 
a different path: to stable "directly". For this specific commit, it 
doesn't matter as the Signed-off-by are for all authors including the 
maintainer as last, but the question remains, I don't believe it's 
always the case the last author Signed-off-by is the same as the 
maintainers' first and last Signed-off-by in the delivery path. What 
should we do?

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 
https://www.kernel.org/doc/html/latest/process or  nor in the vulns git 
repo what to do. Did I miss or misread something? Is there anything we 
could add to 
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html, 
https://www.kernel.org/doc/html/latest/process/cve.html and/or 
https://git.kernel.org/pub/scm/linux/security/vulns.git to make this 
clearer? Greg seems to be saying "patches to vulns.git welcome" in 
http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignment-process/ 
(Chapter "Changing a CVE"). But also "this is automated" in 
http://www.kroah.com/log/blog/2025/12/15/tracking-kernel-commits-across-branches/. 
However, those aren't on kernel.org :)

I hope I got all the right mailing lists and maintainers in the mail 
recipients, feel free to add more appropriate ones.

Cheers,
Quentin

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

[Greg Kroah-Hartman]

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.

> 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.

> 2) I'm also wondering if we should strip the Signed-off-by tags used in the
> original patch's delivery path to Linus. After all, it'll go through a
> different path: to stable "directly". For this specific commit, it doesn't
> matter as the Signed-off-by are for all authors including the maintainer as
> last, but the question remains, I don't believe it's always the case the
> last author Signed-off-by is the same as the maintainers' first and last
> Signed-off-by in the delivery path. What should we do?

Keep the originals please.

> 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.

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.

Hope this helps,

greg k-h

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

[Quentin Schulz]

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