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 Wednesday at 10:01 AM2 days 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 Wednesday at 07:57 PM1 day 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)

The Armbian variant of 2017.09 based for ROCK5B has enough changes/patches such that it runs mainline based Armbian based rockchip64 kernels AFAIK. But never used it on my ROCK5B after many issues with 2017.09 flavors on my ROCK3A, which also was due to PSU (it wants >5V else what should the on-board DC/DC do then).

Inside the EDK2 UEFI v1.1 binary there is also the lower level 2027.09 SPL still but the higher level / bigger functionality should be EDK2 based. I don't know exactly how it is all interacting.

Maybe a warning is that this UEFI based only is fine if you do not need any special HW (from 40-pin header for example). Also if you use GRUB, there is no support for overlays, so the M.2 E-key slot just stays PCIE2x1 instead of SATA6 when you use the Radxa SATA M.2 E-key breakout adapter, which I do. But luckily that setting is in the EDK2 'BIOS' menu and stored in SPI-flash, so even without loading the devicetree, a rolling release distro generic aarch64 kernel (>= 6.19 works I know) and my 8T SATA HDD is there. I made a sort of automatic change in /etc/grub.d/10_linux so the .dtb was loaded, but then panic days later as my HDD kept ticking like bad sector (so dead I thought) when reboot. Of course it overwrites the devicetree done by EDK2 so default to PCIE2x1 for the multi-PHY in the RK35xx.

Also, if boot.scr (or a valid extlinux folder) is found in the first/boot partition, EDK2 UEFI will fall back to that, so make sure to hide/move those. I see I still have this (gdisk -l /dev/nvme0n1)

Number  Start (sector)    End (sector)  Size       Code  Name
   1           32768         1081343   512.0 MiB   EA00  XBOOTLDR partition
   2         1081344        26247167   12.0 GiB    8300  Linux filesystem
   3        26247168        38830079   6.0 GiB     8300  Linux filesystem
   4        38830080        63995903   12.0 GiB    8300  Linux filesystem
   5        63995904        76578815   6.0 GiB     8300  Linux filesystem
   6        76578816       391151615   150.0 GiB   8300  Linux filesystem
   7       391151616       953188351   268.0 GiB   8E00  Linux LVM
   8       953188352       976773119   11.2 GiB    8200  Linux swap

This still works with native/plain/original U-Boot and rk35xx vendor based 6.1 kernel, but I think not in an ARM64 computer that has closed-source UEFI (e.g. like an x86 PC) as that needs ESP, so 0xEF00 instead of 0xEA00

But easy to change, same as un-hiding boot.scr etc. I actually think 0x0700 or 0xEF00 or 0xEA00 all should not matter for U-Boot, at least if there is just 1 path/choice. But if multi OS and the option to store bootpath in SPI-flash (run efibootmgr ), you also can have multiple EFI partitions in theory so not sure what the various bootloaders for ROCK5B will do then. But I keep it simple 1 shared EFI/boot partition.

Another note is that (I think) Armbian Build on Debian Trixie cannot build (older) U-Boot like 2017.09 based, you need (older) Ubuntu for that. I use my ROCK5B Armbian Trixie for building u-boot and kernels, I have no Docker installed as that changes up my networking beyond my own understanding, so for stuff connected to internet, I removed all potential show-stoppers and complexity (for me).

Both Armbian current and edge U-Boot versions (for rock5b) are based on 2017.09, just like the current Radxa bootloader and like the one inside the EDK2 UEFI v1.1 binary (probably dangerous to operate if accessible from the internet).

According to the recent Armbian newsletter an updated bootloader for rockchip64 boards based on U-Boot 2026.10 is on its way. It is probably a good idea to use that one, once available.

Edited 23 hours ago23 hr by ebin-dev

41 minutes ago, ebin-dev said:

Both Armbian current and edge U-Boot versions are based on 2017.09

What repo are you using then? I see this on mine:

~# apt list -i | grep linux-u-boot-rock-5b
linux-u-boot-rock-5b-edge/trixie,now 26.8.3 arm64 [installed]
~# strings /usr/lib/linux-u-boot-edge-rock-5b/u-boot-rockchip-spi.bin | grep "U-Boot SPL 20"
U-Boot SPL 2026.01_armbian-2026.01-S127a-Pab8a-Hc429-Vc955-B5da4-R448a (Aug 14 2026 - 13:24:43 +0000)

Might be bit out-of-date as I use apt pinning, but:

~# cat /etc/os-release 
PRETTY_NAME="Armbian 26.11.0 trixie"

EDIT:

OK I see current is 2017.09 based when I do a test install of that package:

Armbian 'uboot-rock-5b-current' for '2017.09-S39cd-P2e20-Hf5b5-V172f-B5da4-R448a': 'postinst' starting.

So you can use that, depends on what you want/do with your ROCK5B.

Edited 22 hours ago22 hr by eselarm

You were right. The system did not update to the latest os-release, since Armbian updates were commented in armbian.list. I fixed that and updated to the latest release.

The linux-u-boot-current-rock-5b still includes 2017.09, so I have to switch to edge.

# apt list -i | grep linux-u-boot-rock-5b
linux-u-boot-rock-5b-current/now 26.11.0-trunk.129 arm64 [installed,local]

# cat /etc/os-release
PRETTY_NAME="Armbian 26.11.1 trixie"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.7
ID=debian
HOME_URL="https://www.armbian.com"
SUPPORT_URL="https://forum.armbian.com"
BUG_REPORT_URL="https://www.armbian.com/bugs"
ARMBIAN_PRETTY_NAME="Armbian 26.11.1 trixie"

# strings /usr/lib/linux-u-boot-current-rock-5b/idbloader.img | grep "U-Boot SPL 20"
   U-Boot SPL 2017.09_armbian-2017.09-S39cd-P3514-H411a-V172f-B3ba1-R448a (Nov 09 2026 - 13:44:51)

Edited 16 hours ago16 hr by ebin-dev

SPI now contains U-Boot SPL 2026.01 and it boots the current kernel 6.18.63 off emmc:

So in order to make sure there is 'only one captain on the ship' I erased the boodloader on emmc, extracted u-boot-rock-5b-edge and flashed it to SPI:

# erase bootloader on emmc
sudo dd if=/dev/zero of=/dev/mmcblk0 bs=512 seek=64 count=8128 conv=notrunc
sudo dd if=/dev/zero of=/dev/mmcblk0 bs=512 seek=16384 count=16384 conv=notrunc

# erase bootloader on SPI
sudo dd if=zero.img of=/dev/mtdblock0   #zero.img from radxa

# install u-boot 2026.01 to SPI # the name of the linux-u-boot-rock-5b-edge_*.deb package changes frequently
wget https://fi.mirror.armbian.de/beta/pool/main/l/linux-u-boot-rock-5b-edge/linux-u-boot-rock-5b-edge_26.11.0-trunk.129_arm64__2026.01-S127a-Pec93-H9409-Vc955-B3ba1-R448a.deb
mkdir bootloader
dpkg-deb --extract linux-u-boot-rock-5b-edge_26.11.0-trunk.129_arm64__2026.01-S127a-Pec93-H9409-Vc955-B3ba1-R448a.deb ./bootloader
cd ./bootloader/usr/lib/linux-u-boot-edge-rock-5b
sudo dd if=u-boot-rockchip-spi.bin of=/dev/mtdblock0

strings /dev/mtd0 | grep 'U-Boot SPL 20'
   U-Boot SPL 2026.01_armbian-2026.01-S127a-Pec93-H9409-Vc955-B3ba1-R448a (Nov 10 2026 - 12:25:38 +0000)

Edited 2 hours ago2 hr by ebin-dev