I'm running armbian on a Radxa Rock-5b installed around the start of September using Armbian.Imager_2.0.4_amd64.AppImage and picking the Armbian 26.8.3 Minimal Debian 13 image. My current kernel (uname -r) is 6.18.53-current-rockchip64 and apt update && apt info linux-image-\*-rockchip64 | grep -E "^(Package|Version|Source)" reports :

Package: linux-image-bleedingedge-rockchip64

Version: 26.8.8

Source: linux-7.3.0-rc5

Package: linux-image-current-rockchip64

Version: 26.11.0-trunk.56

Source: linux-6.18.53

Package: linux-image-edge-rockchip64

Version: 26.8.8

Source: linux-7.2.8

# cat /etc/apt/sources.list.d/armbian.sources

Types: deb

URIs: http://apt.armbian.com

Suites: trixie

Components: main trixie-utils trixie-desktop

Signed-By: /usr/share/keyrings/armbian-archive-keyring.gpg

CVE-2026-98432 needs a minimum 6.18.56 and CVE-2026-99999 is fixed in 6.18.57.

If you have a PC then easy to setup the armbian build environment and build kernel only, copy the deb files over and run dpkg . The minimum version covering all CVEs is now 5.18.60. I just built mine yesterday and dropped them in …

We have CVE system ready for testing. https://github.com/armbian/build/pull/11166

How it works?

armbian/cve collects kernel security fixes that the stable kernels do not have yet. Stable releases can take weeks to include a fix, and some fixes never reach the older LTS kernels. This repository fills that gap. Tracked kernel series: 6.1, 6.12, 6.18 (LTS) and 7.3 (newest stable).

Where the fixes come from

The fixes come from these sources, in order of preference:

1. stable-queue. These are fixes that the stable maintainers queued for the next point release. They are usually days ahead of the release.

2. Mainline Linux. This is the original fix commit, used when it applies unchanged.

3. The stable mailing list. This is a backport that the fix author posted.

4. Backport with Claude (AI). Some fixes do not apply to an older kernel. Claude adapts these fixes, and a person reviews each one before it goes in.

Two other sources decide what counts as a security fix and how urgent it is:

• The kernel CVE database (vulns.git).

• The CISA list of actively exploited vulnerabilities. A match opens an issue at once.

Fixes that touch only architectures Armbian does not build are skipped. Armbian builds arm, arm64, riscv and x86.

How often

• A check runs every 15 minutes. A full run starts only when a source has changed.

• Each full run that changes the fixes makes a dated release, for example patches-20261104-0022. In practice there are several releases a day.

• Every fix must apply cleanly on the newest stable kernel together with all the other fixes. The set must then compile.

• A fix is removed automatically when the stable kernel includes it. The list does not grow forever.

Current state (2026-11-04)

Series	Base	Fixes waiting for stable
6.1	6.1.191	507
6.12	6.12.115	188
6.18	6.18.60	120
7.3	7.3.1	14

The full list is in report.md. It shows what is included, what still needs a backport, and why. To check one CVE, run ./fasttrack.sh why CVE-XXXX-YYYY in a clone of armbian/cve.

Plan for Armbian images

1. Now: the repository runs and publishes fixes. Armbian images do not use them yet.

2. Next: the build framework gets the option KERNEL_CVE_PATCHES=yes (build#11166, in review). It is off by default. At first it covers the mainline 6.18 (current) and 7.3 (edge) kernels.

3. Then: the scheduled stable image builds turn the option on. Other builds stay without it until the fixes prove reliable.

4. Later: more series, and the default turned on for more builds.

Limits

• Vendor kernels (for example Rockchip 6.1 and the Raspberry Pi kernels) are not covered. They come from separate trees.

• The fixes apply to a kernel only when it is the exact stable version that the fixes were checked on. Otherwise the build skips them and shows a warning.

• "Applies and compiles" does not mean "tested on hardware". Report a problem on the forum or in the repository.

Help

Backports that still need work are listed in report.md under "Needs a backport". CONTRIBUTING.md explains how to help.

That's a lot of words and I'm still left wondering when you'll be publishing the fixes for CVE-2026-98432, rated 9.8/10 on the vulnerability scale, which allows for a root shell to be gained if any tcp port is open on a machine and CVE-2026-99999 which allows a VM running to manipulate the contents of ip packets behind the host's back and can lead to all sorts of nasties. These fixes are in 6.18.56 & 57, 7.2.10 and 11 and 7.3.0 and none of those are currently available for linux-image-\*-rockchip64 and the current installed version is 6.18.53 and uname -a says it was built Sept 21 before any of these CVEs were known.

2 hours ago, TrevorH said:

That's a lot of words

It's an explanation of how we're approaching this problem. IMO better approach then any Linux OS out there. In the age of AI, we won't be doing this kind of operation by hand. But this means whole automation become more complex.

2 hours ago, TrevorH said:

I'm still left wondering when

We're looking for someone who can continuously monitor CVEs, track their status, perhaps improve its design, promote biggest gains and provide answers to questions like yours. System needs to be feed by interactive Claude or 100-150 USD of tokens to drive it fully automatic. Stable repo updating is currently under testing. Only a few kernels will be getting weekly auto-update: https://github.com/armbian/armbian.github.io/blob/main/config/repository-kernel-selection.conf while others will probably need to pass hardware validation.

That role is currently unfilled, and we have no funding allocated to it. Until someone volunteers or funds this specific work, the only answer I can give you is that our best-effort policy applies. I hope by the end of the month all this is in place. Then all CVE's that are resolved are auto-included, while reported ones will require some (serious) work.

So for anyone else looking for these fixes, the newer kernels are all built and available from beta.armbian.com which has 6.18.60 and 7.3.1. They may not be as well tested as the ones in the armbian.sources repo but they are fixed for this remote-root-shell bug. What I did to install them was create /etc/apt/sources.list.d/armbian-beta.sources and /etc/apt/preferences.d/armbian-beta.

root@rock-5b:~# cat /etc/apt/sources.list.d/armbian-beta.sources
Types: deb
URIs: http://beta.armbian.com
Suites: trixie
Components: main trixie-utils trixie-desktop
Signed-By: /usr/share/keyrings/armbian-archive-keyring.gpg

root@rock-5b:~# cat /etc/apt/preferences.d/armbian-beta
Package: *
Pin: origin beta.armbian.com
Pin-Priority: 1

Package: linux-image-current-rockchip64 linux-image-bleedingedge-rockchip64 linux-image-edge-rockchip64
Pin: origin beta.armbian.com
Pin-Priority: 995

This adds the beta repo and then sets all packages to have a lower priority than the non-beta ones except for the linux-image-*-rockchip64 packages which are a higher preference than the non-beta ones so they are picked up first. Since the 7.3 kernel is now GA upstream and I want the scheduler improvements that are in 7.3, I chose to install linux-image-edge-rockchip64 which is currently 7.3.1.

I am using the latest linux-image-current-rockchip64 kernels from beta.armbian.com (branch 6.18) and there are no issues booting off emmc on a headless rock5b (data on nvme).

However, I would like to switch to linux-image-edge-rockchip64 (branch 7.3; for security reasons), but my system does not boot from emmc anymore once the new 7.3 kernel image (incl dtb and headers) is installed. What might be the issue here ?

Should I first update the boot loader on SPI to a more recent version ? Currently the following version is used: U-Boot SPL 2017.09-gd1cf49135ee-220414 #stephen (May 23 2024 - 18:47:18).

# cat /proc/cmdline

root=UUID=e0d1f6a8-8612-4976-9917-redacted rootwait rootfstype=ext4 splash=verbose console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart=903a1366-4ff1-449e-8e71-redacted usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u,0x152d:0x0578:u   cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory androidboot.fwver=ddr-v1.16-9fffbe1e78,bl31-v1.45,uboot-d1cf49135e-05/23/2024

Package: linux-image-current-rockchip64

Version: 26.11.0-trunk.126

Source: linux-6.18.62

Edited 18 hours ago18 hr by ebin-dev

7 hours ago, ebin-dev said:

Should I first update the boot loader on SPI to a more recent version ? Currently the following version is used: U-Boot SPL 2017.09-gd1cf49135ee-220414 #stephen (May 23 2024 - 18:47:18).

Yes, it is not even Armbian U-boot; ROCK5B is very well supported, any recent mainline based U-Boot will even run a normal Debian Sid kernel (7.3.3+deb14-arm64 currently, I have that running currently, not U-Boot in SPI-flash, but EDK2 EUFIv1.1). But for old BananaPi I used Armbian Build to have 2026.07 with some Btrfs compress fix, so boots/runs 7.3.3-edge-sunxi directly from rootfs all compressed zstd.

I do not have eMMC module, only SPI-flash (and SD-card for emergencies maybe). So I am sure I only have 1 bootloader (in SPI-flash). You might have 2, also in eMMC. Make sure you wipe old/double/redundent ones so only '1 captain on the ship'.

1 hour ago, eselarm said:

Yes, it is not even Armbian U-boot; ROCK5B is very well supported, any recent mainline based U-Boot will even run a normal Debian Sid kernel (7.3.3+deb14-arm64 currently, I have that running currently, not U-Boot in SPI-flash, but EDK2 EUFIv1.1). But for old BananaPi I used Armbian Build to have 2026.07 with some Btrfs compress fix, so boots/runs 7.3.3-edge-sunxi directly from rootfs all compressed zstd.

I do not have eMMC module, only SPI-flash (and SD-card for emergencies maybe). So I am sure I only have 1 bootloader (in SPI-flash). You might have 2, also in eMMC. Make sure you wipe old/double/redundent ones so only '1 captain on the ship'.

Very interesting - thanks for the reply!

The boot loader in SPI flash is the current one from radxa (outdated). To zero an extra one on emmc is not so difficult.

But I am not sure how to flash something like EDK2 EUFIv1.1 to SPI. Could you describe the steps of obtaining and flashing the boot loader you use ? (or a recent u-boot version)

If booting off emmc goes wrong I would boot from SD and revert back the boot loader to the current one.

Edited 8 hours ago8 hr by ebin-dev

Download the file from https://github.com/edk2-porting/edk2-rk3588/releases

Then:

sudo flashcp -v -p --erase-all ./rock-5b_UEFI_Release_v1.1.img /dev/mtd0

Or use armbian-install to write the u-boot binary from the currently installed u-boot package.

The EDK2 bootloader is most convenient when you have/use dedicated boot/EFI system partition and GRUB as bootmanager, so just like a x86 PC, also nice setup screen before kernel etc loads. U-Boot need serial console cable to do things before kernel load, it usually does not initialize HDMI fast enough is my experience.

As a data point I am running kernel 7.3.3 and booting from nvme and strings /dev/mtd0 | grep U-Boot\ 2 says U-Boot 2017.09_armbian-2017.09-S39cd-P3cf6-Hf5b5-V172f-B6a81-R448a (Sep 14 2026 - 22:38:37 +0000)