Kernel update - [amd64-rt, amd64-generic, amd64-generic, arm64-generic, arm64-generic, arm64-nvidia-jp7, riscv64-generic] by christoph-zededa · Pull Request #6180 · lf-edge/eve

christoph-zededa · 2026-07-20T11:21:46Z

Description

Update kernel-commits.mk to the latest commits of the lf-edge/eve-kernel branches, generated with tools/update_kernel_commits.py, and move amd64 to the new eve-kernel-amd64-v6.12.96-generic branch.

The arm64 and riscv64 pins 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)

amd64 instead moves from the v6.12.49 to the v6.12.96 eve-kernel branch, i.e. from upstream stable Linux 6.12.49 to 6.12.96 (47 point releases), and kernel-version.mk is bumped accordingly. Both KVM shadow-paging fixes are in upstream 6.12.96, as is the af_alg CVE-2026-31431 fix that v6.12.49-generic carried as a backport. The EVE patch stack (37 patches) was rebased onto the new tag unchanged, with one exception: Makefile.eve: make linuxkit tmp dir user-specific is not present on the new branch (build tooling only, no runtime effect). docs/KERNEL.md is updated to match, in a separate commit.

Updated pins used by this branch:

eve-kernel branch	old	new
`eve-kernel-amd64-v6.12.49-generic` → `eve-kernel-amd64-v6.12.96-generic`	`dcdba3ddf871`	`bfc617435842`
`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.177-generic, arm64-v6.1.112-generic); these entries are inert for master builds. The inert amd64 6.1.x pin now tracks the new v6.1.177 branch instead of v6.1.112. 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: the amd64 kernel moves to upstream stable Linux 6.12.96 (from 6.12.49), and arm64/riscv64 pick up two KVM x86 shadow-paging use-after-free fixes.

PR Backports

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: 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 · 2026-07-20T13:16:47Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 23.31%. Comparing base (5d69266) to head (3afb62b).
⚠️ Report is 8 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6180      +/-   ##
==========================================
+ Coverage   22.93%   23.31%   +0.37%     
==========================================
  Files         510      520      +10     
  Lines       93473    95189    +1716     
==========================================
+ Hits        21440    22190     +750     
- Misses      70292    71074     +782     
- Partials     1741     1925     +184

☔ 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 · 2026-07-20T22:45:06Z

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 · 2026-07-21T10:01:35Z

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 · 2026-07-21T13:56:06Z

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 · 2026-07-21T14:18:24Z

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 · 2026-07-21T14:28:00Z

@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 · 2026-07-21T14:30:25Z

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 · 2026-07-21T14:42:45Z

@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 · 2026-07-21T14:46:50Z

@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 · 2026-07-21T17:37:39Z

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

eriknordmark · 2026-07-21T18:25:05Z

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

christoph-zededa · 2026-07-22T08:50:14Z

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

That is how our project is currently set up (branch is specific for micro version and I cannot create a new branch)
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 · 2026-07-22T10:27:54Z

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 · 2026-07-22T17:49:24Z

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 · 2026-07-23T11:06:59Z

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

christoph-zededa · 2026-07-28T21:23:09Z

/rerun red

This commit changes: eve-kernel-amd64-v6.12.96-generic bfc617435842: Makefile.eve: Set kernel version to 6.12.96 513d44fe2f68: KVM: x86/mmu: emulate (not -EFAULT) guest access to a disabled passthrough BAR d5cf6db669bd: vfio/pci: Set up BAR resources and maps in vfio_pci_core_enable() 14c0ab4408c5: Dockerfile.gcc: bump ZFS to 2.3.6 fc2b2d7e8d8c: GHA: targeted cleanup — preserve BuildKit ccache across runs 26c351a70659: GHA: pin actions to commit SHAs and bump to latest versions 77b1f5d7e31f: Makefile.eve: use linuxkit pkg build for kernel build 0c6334cdab08: Makefile.eve: pin linuxkit to upstream master tip 7a637697296d: Makefile.eve: flexible linuxkit acquisition, drop manual builder setup e24d3a76f5ec: Add cleanup steps to CI workflows and Makefile 1fab3342f815: Enable NUMA and NUMA balancing 18609908513f: configs: Disable INTEL_PCH_THERMAL driver 9239af580bbf: [rt] Adjust rt.fragment according to Intel recommendations 39809ebe29a2: Add RT patch download/apply to rt-config and rt-clean target 0084072d4c71: Re-enable cgroup v1 support f9d6e74deb7f: Improve kernel compression 81da20db5cf5: Update kernel tag for 6.12.49 and push named branch 9e7a4bb60a97: [hwe] Enable UAS for USB 2ec3b739aa98: [core,hwe] Add proper support for Siemens IPC devices b3c1ca585eb1: gha: add GHA and add 'rt' flavor to the matrix 3c77ada27420: [rt] Add CONFIG_X86_CPU_RESCTRL for Intel CAT 815f1633dcb7: [rt] Add RT config generation using fragment e53a51d2fe0e: Bump ZFS version to 2.3.3 fe626a1d906e: Adopt drivers/usb/serial/xr_usb_serial_common.c for kernel 6.12 c45389115367: Update configs to 6.12.49 dcb3b01c586d: MFD: Add JUMPtec/Kontron PLD drivers (kempld) 4bfd02bd78a3: Enable RS485 mode for USB_SERIAL_XR_RS485 facb93e81d80: Add USB MaxLinear/Exar USB to Serial driver. Version 1G b4082a0b6342: bpf: lockdown for security 11df13a9e3aa: stmmac: Do not enable/disable runtime PM for PCI devices 46cd7afdcedb: Override ACS capability even if it is supported by device afbec254dca5: Add support for EM321 platform devices 25b31ca3bbd2: Add support for LEDs on Operational Services EM320 device 268ce016f3a7: Quirk for brocken INTx on Euresys Grablink Full XR 72cb0d25c008: ACS override patch 0b1bc50d43fd: Integrate build files from v6.1.112 branch 27886b02af9c: Initial kernel configs from 6.1.38 kernel eve-kernel-arm64-v6.1.155-generic 417a12ac3d50: Makefile.eve: make linuxkit tmp dir user-specific ad07c79db038: KVM: x86: Fix shadow paging use-after-free due to unexpected role 73eada660b80: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN eve-kernel-arm64-v6.8.12-nvidia-jp7 7f5919c0eaef: Makefile.eve: make linuxkit tmp dir user-specific c4b76b8d40ce: KVM: x86: Fix shadow paging use-after-free due to unexpected role 08d72f7bb0c1: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN eve-kernel-riscv64-v6.1.112-generic bd5816893ca9: Makefile.eve: make linuxkit tmp dir user-specific 385a8712783d: KVM: x86: Fix shadow paging use-after-free due to unexpected role 2e746af4691d: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN Signed-off-by: Christoph Ostarek <christoph@zededa.com>

The amd64 generic/rt kernel moved from the eve-kernel v6.12.49 branch to v6.12.96. Update the current-version list, the branch-name examples and the pinned commit shown in the kernel-commits.mk sample. Signed-off-by: Christoph Ostarek <christoph@zededa.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

github-actions Bot requested a review from eriknordmark July 20, 2026 11:22

christoph-zededa added stable Should be backported to stable release(s) security Provides a security fix labels Jul 20, 2026

christoph-zededa marked this pull request as ready for review July 20, 2026 13:22

christoph-zededa added the next-17.0.0-rc label Jul 20, 2026

christoph-zededa mentioned this pull request Jul 21, 2026

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

Draft

9 tasks

eriknordmark removed the next-17.0.0-rc label Jul 21, 2026

christoph-zededa force-pushed the bump_eve_kernel branch 3 times, most recently from b266b00 to 7e63430 Compare July 28, 2026 21:12

christoph-zededa force-pushed the bump_eve_kernel branch from 7e63430 to 3afb62b Compare July 29, 2026 12:37

Uh oh!

Conversation

christoph-zededa commented Jul 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

How to test and validate this PR

Changelog notes

PR Backports

Checklist

Uh oh!

codecov Bot commented Jul 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

eriknordmark commented Jul 20, 2026

Uh oh!

christoph-zededa commented Jul 21, 2026

Uh oh!

rene commented Jul 21, 2026

Uh oh!

christoph-zededa commented Jul 21, 2026

Uh oh!

eriknordmark commented Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

christoph-zededa commented Jul 21, 2026

Uh oh!

rene commented Jul 21, 2026

Uh oh!

rene commented Jul 21, 2026

Uh oh!

eriknordmark commented Jul 21, 2026

Uh oh!

eriknordmark commented Jul 21, 2026

Uh oh!

christoph-zededa commented Jul 22, 2026

Uh oh!

rene commented Jul 22, 2026

Uh oh!

eriknordmark commented Jul 22, 2026

Uh oh!

rene commented Jul 23, 2026

Uh oh!

christoph-zededa commented Jul 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

christoph-zededa commented Jul 20, 2026 •

edited

Loading

codecov Bot commented Jul 20, 2026 •

edited

Loading

eriknordmark commented Jul 21, 2026 •

edited

Loading