Kernel update - [amd64-rt, amd64-generic, amd64-generic, arm64-generic, arm64-generic, arm64-nvidia-jp7, riscv64-generic]

[christoph-zededa]

Description

Update kernel-commits.mk to the latest commits of the lf-edge/eve-kernel branches, generated with tools/update_kernel_commits.py.

All kernels consumed by builds from this branch pick up the same three changes:

• KVM: x86: Fix shadow paging use-after-free due to unexpected role
• KVM: x86: Fix shadow paging use-after-free due to unexpected GFN
• Makefile.eve: make linuxkit tmp dir user-specific (kernel build tooling; no runtime change)

Updated pins used by this branch:

eve-kernel branch	old	new
eve-kernel-amd64-v6.12.49-generic	dcdba3ddf871	0aa61a5e9639
eve-kernel-arm64-v6.1.155-generic	9fa67514972d	417a12ac3d50
eve-kernel-arm64-v6.8.12-nvidia-jp7	452eaffef5ed	7f5919c0eaef
eve-kernel-riscv64-v6.1.112-generic	30aa75d58cdd	bd5816893ca9

amd64-next, nvidia-jp5 and nvidia-jp6 pins are unchanged. The update also re-adds pins for eve-kernel branches that exist upstream but are not referenced by kernel-version.mk on master (amd64-v6.1.111-rt, amd64-v6.1.112-generic, arm64-v6.1.112-generic); these entries are inert for master builds. See the commit message for the full per-branch changelogs.

Docker Hub images for all new pins were verified to exist, including the amd64 core and rt config flavors.

How to test and validate this PR

• The PR gate builds every supported ZARCH/PLATFORM combination against the new pins, which validates that the pinned kernel images are pullable and usable.
• Local validation: make live && make run-live; the device should boot normally and uname -r inside EVE reports a kernel version string containing the new short commit hash of the pinned kernel.
• The KVM shadow-paging fixes are exercised by deploying/booting any VM app instance; make eden TEST_SMOKE=1 covers app-instance deployment end to end.

Changelog notes

Kernel update for all supported platforms, including two KVM x86 shadow-paging use-after-free fixes.

PR Backports

• 17.0 (release branch): Yes — [17.0] Kernel update - [amd64-rt, amd64-generic, amd64-generic, arm64-generic, arm64-generic, arm64-nvidia-jp7, riscv64-generic] #6191
• 16.0-stable: Yes — [16.0-stable] Kernel update - [amd64-rt, amd64-generic, amd64-generic, arm64-generic, arm64-generic, arm64-nvidia-jp7, riscv64-generic] #6183
• 14.5-stable: Yes — [14.5-stable] Kernel update - [amd64-generic, amd64-generic, arm64-generic, arm64-generic, arm64-nvidia-jp7, riscv64-generic] #6182
• 13.4-stable: Yes — [13.4-stable] Kernel update - [amd64-next, amd64-generic, amd64-generic, arm64-nvidia-jp5, arm64-nvidia-jp6, arm64-generic, arm64-generic, arm64-nvidia-jp7, riscv64-generic] #6181

The stable-branch PRs are not cherry-picks: the update script was re-run against each branch's own kernel set.

Checklist

• I've provided a proper description
• I've added the proper documentation
• I've tested my PR on amd64 device
• I've tested my PR on arm64 device
• I've written the test verification instructions
• I've set the proper labels to this PR

And the last but not least:

• I've checked the boxes above, or I've provided a good reason why I didn't
  check them: no documentation changes are needed for a kernel pin bump; device testing is pending while this PR is in draft (CI + QA validation to follow); the stable label should be set as this update is mirrored to all current LTS branches.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 23.00%. Comparing base (40d245c) to head (5d3fc7e).
⚠️ Report is 4 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6180      +/-   ##
==========================================
+ Coverage   22.61%   23.00%   +0.38%     
==========================================
  Files         507      517      +10     
  Lines       93223    94939    +1716     
==========================================
+ Hits        21084    21838     +754     
- Misses      70413    71194     +781     
- Partials     1726     1907     +181     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[eriknordmark]

Technically we don't need to update ARM64 since it is not exposed to this bug. Do we still wanr to do those updates?

The naming of the eve-kernel branches makes it look they they still have old code; we need 6.12.95 - is that what we get from the eve-kernel-amd64-v6.12.49-generic branch? That is confusing!

Note that 17.0 needs an update as well but it is not in the backport list.

[christoph-zededa]

Technically we don't need to update ARM64 since it is not exposed to this bug. Do we still wanr to do those updates?

I would say for consistency we can include them; also it makes future kernel bump PRs easier to read if they do not have to mention this fix.

Note that 17.0 needs an update as well but it is not in the backport list.

I though this is done by adding the "next-17.0.0-rc" label so that this commit will get cherry-picked into the 17.0 branch.

[rene]

Technically we don't need to update ARM64 since it is not exposed to this bug. Do we still wanr to do those updates?

That's right, but I agree with @christoph-zededa , we can keep it for consistence.... although it's not mandatory nor critical to bump it now...

The naming of the eve-kernel branches makes it look they they still have old code; we need 6.12.95 - is that what we get from the eve-kernel-amd64-v6.12.49-generic branch? That is confusing!

@eriknordmark , I didn't get your point, why you mentioned 6.12.95? We don't support this kernel, the latest for amd64 is 6.12.49....

Note that 17.0 needs an update as well but it is not in the backport list.

Correct, @christoph-zededa , regardless the label, please, add it to the backport list as well...

[christoph-zededa]

Note that 17.0 needs an update as well but it is not in the backport list.

Correct, @christoph-zededa , regardless the label, please, add it to the backport list as well...

The backport can be found here: #6191

[eriknordmark]

@eriknordmark , I didn't get your point, why you mentioned 6.12.95? We don't support this kernel, the latest for amd64 is 6.12.49....

The CVE is fixed in 6.12.95, right? That's what my CVE reachability analysis told me.

I can'te tell from the name of the eve-kernel branch what is in it, and the name has .49 in it which is extermely confusing.
Shouldn't we (potentially separately) change the name of the TAGs to not include the minor release version?

[christoph-zededa]

The CVE is fixed in 6.12.95, right? That's what my CVE reachability analysis told me.

I can'te tell from the name of the eve-kernel branch what is in it, and the name has .49 in it which is extermely confusing. Shouldn't we (potentially separately) change the name of the TAGs to not include the minor release version?

It is also fixed in "our" 6.12.49 as lf-edge/eve-kernel#258 has been merged.

[rene]

@eriknordmark , I didn't get your point, why you mentioned 6.12.95? We don't support this kernel, the latest for amd64 is 6.12.49....

The CVE is fixed in 6.12.95, right? That's what my CVE reachability analysis told me.

I can'te tell from the name of the eve-kernel branch what is in it, and the name has .49 in it which is extermely confusing. Shouldn't we (potentially separately) change the name of the TAGs to not include the minor release version?

Yes you can, the branch is named exactly to the version which the sources belong to: eve-kernel-amd64-v6.12.49-generic branch contains the sources for 6.12.49 version, you can confirm looking to the Makefile: https://github.com/lf-edge/eve-kernel/blob/eve-kernel-amd64-v6.12.49-generic/Makefile . @christoph-zededa ported the fix from master, I still don't get it when you say this sources belong to 6.12.95....

[rene]

@eriknordmark , I didn't get your point, why you mentioned 6.12.95? We don't support this kernel, the latest for amd64 is 6.12.49....

The CVE is fixed in 6.12.95, right? That's what my CVE reachability analysis told me.
I can'te tell from the name of the eve-kernel branch what is in it, and the name has .49 in it which is extermely confusing. Shouldn't we (potentially separately) change the name of the TAGs to not include the minor release version?

Yes you can, the branch is named exactly to the version which the sources belong to: eve-kernel-amd64-v6.12.49-generic branch contains the sources for 6.12.49 version, you can confirm looking to the Makefile: https://github.com/lf-edge/eve-kernel/blob/eve-kernel-amd64-v6.12.49-generic/Makefile . @christoph-zededa ported the fix from master, I still don't get it when you say this sources belong to 6.12.95....

I think now I understood the confusion, to clarify, @christoph-zededa is not bumping the kernel to 6.12.95 to get the fix, he ported the fix for the CVE from master to our 6.12.49, so our version is still 6.12.49 wit the fix for the CVE + some of our patches, as usual....

[eriknordmark]

It seems undesirable to port individual patches. Why not move to the new micro kernel version instead?

[eriknordmark]

Let's target 17.0.1 for this. Removing the 17.0.0 label.

[christoph-zededa]

It seems undesirable to port individual patches. Why not move to the new micro kernel version instead?

1. That is how our project is currently set up (branch is specific for micro version and I cannot create a new branch)
2. It is a lot harder to review and to test

I created a branch for 6.12.96 here: https://github.com/christoph-zededa/eve-kernel/tree/eve-kernel-amd64-v6.12.96-generic

[rene]

It seems undesirable to port individual patches. Why not move to the new micro kernel version instead?

well, that's not that simple for kernel, first we can't always just bump to the minor release because we have many different kernel versions, for instance, bumping from 6.1.x, 5.15.x would not be feasible in this case. Second, even for this particular case (only x86 affected), bumping from 6.12.49 to 6.12.95 represents a diff of 8380 commits, do we really want to introduce all these changes only because of a single fix? AFAIK our policy is still to bump kernel once a year... IMHO I would prefer to keep control of our changes and only introduce the fix for now.... we can get an analyses from Claude on the changes as well and make a decision, but 8380 commits is not something we can just neglect....

[eriknordmark]

It seems undesirable to port individual patches. Why not move to the new micro kernel version instead?

well, that's not that simple for kernel, first we can't always just bump to the minor release because we have many different kernel versions, for instance, bumping from 6.1.x, 5.15.x would not be feasible in this case. Second, even for this particular case (only x86 affected), bumping from 6.12.49 to 6.12.95 represents a diff of 8380 commits, do we really want to introduce all these changes only because of a single fix? AFAIK our policy is still to bump kernel once a year...

Our intent is to bump the major/minor version once a year to move to the next kernel LTS. But we've bumped the micro version at other times.

I suspect all the other Linux distros which want to address this CVE just bumps the micro version in their master/main build. Is there evidence that they cherry-pick individual kernel CVE patches?

[rene]

It seems undesirable to port individual patches. Why not move to the new micro kernel version instead?

well, that's not that simple for kernel, first we can't always just bump to the minor release because we have many different kernel versions, for instance, bumping from 6.1.x, 5.15.x would not be feasible in this case. Second, even for this particular case (only x86 affected), bumping from 6.12.49 to 6.12.95 represents a diff of 8380 commits, do we really want to introduce all these changes only because of a single fix? AFAIK our policy is still to bump kernel once a year...

Our intent is to bump the major/minor version once a year to move to the next kernel LTS. But we've bumped the micro version at other times.

I suspect all the other Linux distros which want to address this CVE just bumps the micro version in their master/main build. Is there evidence that they cherry-pick individual kernel CVE patches?

I don't have an "evidence" for main distros to show, but I'm very use to see patches with not only CVEs but other smalls fixes just backported to kernels from BSPs. Claude said the following:

They port (backport) the patch. Distros almost never bump the kernel's minor version to fix a CVE—doing so would pull in thousands of unrelated changes, break the stable ABI/KMI guarantees they promise, and risk regressions.

The standard workflow is:

The distro tracks a fixed base version (e.g. RHEL ships 5.14, Ubuntu LTS ships some 5.15/6.8, Debian pins a version for a release).
When a CVE is fixed upstream, they take the specific commit(s), cherry-pick/adapt them to their older tree (adjusting context, dependencies, and any prerequisite commits), and release it as a new package revision (e.g. 5.14.0-427.el9).
The version string stays on the same base; only the distro's own release/revision number increments.

This is exactly what the upstream stable/longterm trees (linux-stable, maintained by Greg KH) exist to make easier—Greg's team backports fixes into e.g. 6.6.y, 6.1.y, 5.15.y, and distros often pull from those or use them as a reference.

Debian and SUSE frequently rebase onto the corresponding stable point release (so the third number does move, e.g. 6.1.90 → 6.1.99), but that's staying within the same longterm series, not jumping the minor version. Red Hat and Oracle tend to do more manual per-CVE backporting onto a frozen base.

The practical upshot: a distro kernel's version number tells you almost nothing about which CVEs are patched. You have to check the changelog or the distro's CVE tracker, because a "5.14" RHEL kernel may contain fixes that upstream only landed in 6.x.

Again, I'm not against bump the minor version if we want to get more fixes, improvements, etc, provided by the 6.12.95, but not just because of the CVE fix....