TrevorH

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)

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: 995This 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.

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.

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.

I have an rk3588 based board running minimal Armian Debian 13 and it is on 6.18.53 and sees no updates and is using linux-image-current-rockchip64

The 6.1 kernel is an LTS one though the current upstream version is 6.1.190.

Google says the S905L3A has cpu cores that are all the same so it is not the cause of the problem.

Are all the armbian machines that are affected using a mixture of different cpu cores/speeds? The Neo4 uses a mixed big:LITTLE set up, do the others also do so?

It is highly likely that a realtek onboard device will use a different driver to a USB attached one. I have a UGreen 2.5Gb USB adapter that uses the r8152 driver and my Radxa Rock-5b has an RTL8125 pcie device that uses the r8169 driver. Sure there might be code reuse between them but they are a different driver.

The 7.3.0 kernel fixes another problem I reported where the RK3588 only uses 7 cores out of 8 under heavy load which is why I installed it (first on rc3 then updated to rc4). I did notice that on upgrade from rc3 to rc4 the network performance dropped slightly but not enough to bother about. But iso9660 being broken is more problematic when this is my PXE host with loads of iso images on it so I can boot what I choose. I don't care about graphics as this is a headless box. ISO corruption is more annoying than a maximum 87.5% cpu usage so I'll go back to the -current- series for now. I'll wait for Linus to release 7.3.0 before I try again as it seems like a good choice since it's quite likely to be the next LTS candidate.

Thanks for confirming it's fixed in a later version already. I see other problems being reported with rc6 so I'll stick with the older 6.18 for now, probably until 7.3.0 is released as current upstream.

I think it is probably this https://lore.kernel.org/lkml/20260922054853.469681-1-matthias.goergens@gmail.com/

I was using 7.3.0 as it fixes the scheduler bug. I figured someone would want to know it was broken.

I have a recently commissioned Radxa Rock-5B that I use as my PXE host. It has a number of iso images that are loopback mounted on directories like /var/www/html/mirrors/Fedora-44. I recently attempted an install of Fedora 44 on a VM and it crashed, complaining that it was unable to download a package from /var/www/html/mirrors/Fedora-44/Packages/p/parted-3.6-14.fc44.x86_64.rpm. I checked the directory on the Rock-5B and it was indeed missing but it was also giving me a lot of output that looked like -r--r--r-- 1 root root 264876 Feb 2 2026 policycoreutils-3.10-1.fc44.x86_64.rpm ?????????? ? ? ? ? ? policycoreutils-newrole-3.10-1.fc44.x86_64.rpm all files from here are the same ??? I checked the sha256sum of the Fedora 44 iso against the one published on the website and it matches. I renamed the file and downloaded a fresh copy, just in case, same size, same sha256sum, same errors. I rebooted the Rock-5B to see if it was a transient problem but it was still broken on reboot. I copied the iso file to a different system running an older kernel and mounted it there and the content was correct and there were no errors and more importantly the parted-3.6 rpm file it complained about was present. I removed linux-image-bleedingedge-rockchip64 and rebooted into Linux rock-5b 6.18.53-current-rockchip64 and the problem was gone. It seems something about loopback mounting iso images is broken in 7.3.0-rc4. I have not tried a more recent bleedingedge version yet.

I don't think 192.168.1.255 is a very good choice of ip address as it will be the broadcast address for the 192.168.1.0/24 subnet. It's very unlikely to be a cause for the problem you have but it's probably something you should change.