virtualbox.org

(Fedora 43) - cr4_read_shadow/cr4_update_irqsoff namespace restriction

Description:
VirtualBox 7.1.16 (r172425) kernel modules fail to build on
kernel 6.19.6-200.fc43.x86_64.

modpost fails with:
ERROR: modpost: module vboxdrv uses symbol cr4_update_irqsoff
from namespace module:kvm,kvm-amd,kvm-intel, but does not import it.
ERROR: modpost: module vboxdrv uses symbol cr4_read_shadow
from namespace module:kvm,kvm-amd,kvm-intel, but does not import it.

Attempting MODULE_IMPORT_NS() results in:
ERROR: modpost: vboxdrv: explicitly importing namespace
"module:kvm,kvm-amd,kvm-intel" is not allowed.

The kernel commit that caused this likely moved these symbols
into a protected module namespace that cannot be imported by
out-of-tree modules.

KBUILD_MODPOST_WARN=1 also does not bypass this error.

Host OS: Fedora 43
Kernel: 6.19.6-200.fc43.x86_64
VirtualBox: 7.1.16r172425

Workaround: Boot with kernel 6.18.x

If the Kernel Update was released after the last VirtualBox version Update then build failures are to be expected. Apart from rolling back to the last working kernel version, you could try updating to the latest VirtualBox Test Build from https://www.virtualbox.org/wiki/Testbuilds which will contain any already applied code fixes/updates pending the next stable release, which tend to be at around 3 month intervals.

Thank you very much for this idea. Was busy all day and now it's late. I'll try tomorrow. Best regards, Michael

I have now installed VirtualBox 7.2.6 and the new Kernel 6.19.7. Same problem. This is a deeper issue of VirtualBox with Kernel Line 6.19. Only solution as of now is to revert back to Kernel 6.18. This needs to be fixed by Oracle. Kernel 6.19 introduces a KVM-Symbol-Namespace-Lock and that breaks VirtualBox.

@multiOS Thanks again for your tip. I looked into the testbuilds. Problem is, for Fedora they only have the .run version (not an rpm). I've had bad experience with .run under Fedora, so I don't dare to use that. And whether an Oracle Linux Version (they are rpm), and if so, which of the 3 versions presented there, could run, I've had no time to test. By the way, with VirtualBox 7.2 even a third locked symbol was introduced: __flush_tlb_all. This definitely needs to be fixed by Oracle, until then, one can only revert to Kernel 6.18 - which will be a BIG problem as soon as Fedora 44 comes around, and which is expected in April or so. Kind regards

As reverting to 6.18 works, one could use copr repo with kernel-longterm-6.18 package for fedora 43/44 if for some reason previous kernels were removed or not available for the system - tested today on FC43 and working with current VirtualBox fedora package.

Staying on 6.18 is fine as a short term solution but it's a month on now.

AFAICT the test builds resolve the issue. RPMs on download.virtualbox. org were last updated in January. When are new ones expected?

In a week.

Thanks Klaus!

Not for the 7.1.xx branch, though. I've just tested 7.1.17 r173555 on Fedora 42 kernel 6.19.12 and the issue is still there.

Anyway those were from April 9th. Given that a new version will be released soon which is hopefully compatible, I'll wait a bit longer.

FranceBB wrote: ↑19. Apr 2026, 17:17 Not for the 7.1.xx branch, though. I've just tested 7.1.17 r173555 on Fedora 42 kernel 6.19.12 and the issue is still there.

Anyway those were from April 9th. Given that a new version will be released soon which is hopefully compatible, I'll wait a bit longer.

It looks like that fresh 7.1.18 (r173720) version finally works ! [Fedora 43, kernel 6.19.12-200]. What is interesting, after start of VM this VM goes automatically into the fullscreen mode ... but HostKey+F switch works, so ... it doesn't matter too much.

VirtualBox 7.2.8 was published yesterday, and I can confirm that on my system this new version is working with Kernel 6.19 now.

Can confirm, upgrade from VirtualBox-7.1-7.1.16 on fedora 6.18 to VirtualBox-7.1-7.1.18 on fedora 6.19.12 was smooth, simple, and Just Worked.

Thanks everyone!