Bug 2464626

Summary:	Modules in recent ELN kernel builds are incorrectly signed
Product:	[Fedora] Fedora	Reporter:	Adam Williamson <awilliam>
Component:	kernel	Assignee:	Justin M. Forbes <jforbes>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	acaringi, adscvr, airlied, hans, hpa, jforbes, kernel-maint, linville, masami256, mchehab, nickolasjcarr, ptalbert, sardella, steved, suraj.ghimire7, yselkowi
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2026-06-25 20:38:56 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Adam Williamson 2026-05-02 06:01:50 UTC

Current Fedora ELN kernels have incorrectly signed modules. They do not load, with an error like this:

modprobe dm_mod gives modprobe: ERROR: could not insert 'dm_mod': Key was rejected by service

and if you run modinfo on them, the signature field is improbably long.

This seems to really be due to something in the kernel itself. I tried rebuilding both kernel-7.0.0-62.eln156 and kernel-7.1.0-0.rc1.260501g26fd6bff2c050.13.eln156 with the same buildroot (the last available ELN compose at the time, https://kojipkgs.fedoraproject.org/compose/eln/Fedora-eln-20260416.n.2/compose ). The 7.1.0 kernel build shows the improbably long module signatures. The 7.0.0 build does not.

Unfortunately we were missing ELN kernel builds for a while, so the tightest delta we have here is that it broke between kernel-7.0.0-62.eln155 and kernel-7.1.0-0.rc1.260428g3b3bea6d4b9c1.10.eln156 .

Comment 1 Adam Williamson 2026-05-02 06:05:06 UTC

Note this does not, for some reason, affect Rawhide. The Rawhide kernel builds have correctly-signed modules that load. It's only the ELN builds that have the issue.

Comment 2 Justin M. Forbes 2026-05-05 17:37:03 UTC

I expect this will be fixed with kernel-7.1.0-0.rc2.260505ga293ec25d59dd.17
I have also opened an MR to have RHEL change their config appropriately, and marked it include in release until such time as we have acks and a merge.

Root cause is that RHEL/ELN changed to CONFIG_MODULE_SIG_KEY_TYPE_MLDSA_87 from CONFIG_MODULE_SIG_KEY_TYPE_RSA.  Rawhide is still using RSA becaus the MLDSA_87 option specifically mentions that it needs openssl 4.0 to be fully functional. The 7.0 build did work because of openssl 4.0 being in the ELN root temporarily.  Without openssl 4.0 we must also enable PKCS7_WAIVE_AUTHATTRS_REJECTION_FOR_MLDSA. The Kconfig description follows.

Due to use of CMS_NOATTR with ML-DSA not being supported in
OpenSSL < 4.0 (and thus any released version), enabling this
allows authenticatedAttributes to be used with ML-DSA for
module signing.  Use of authenticatedAttributes in this
context is normally rejected.

Comment 3 Adam Williamson 2026-05-05 19:17:14 UTC

Thanks a lot for figuring that out. We'll confirm it works when the ELN rebuild happens.

Comment 4 Adam Williamson 2026-05-06 06:23:25 UTC

Unfortunately that does not seem to have entirely done the trick :( 7.1.0-0.rc2.260505ga293ec25d59dd.17.eln156 failed openQA tests, the compose it's in also fails to boot, and the signatures on modules in it still look very long.

Looking at the video of one failed test I do see this message:

PCKS7: Waived invalid module sig (has authattrs)

which implies setting the option did what it's meant to do, but...we're still not booting successfully.

Testing manually in my local VM, I still get `modprobe: ERROR: could not insert 'dm_mod': Key was rejected by service` when trying to do `modprobe dm_mod` in the rescue environment after boot fails.

Comment 5 Yaakov Selkowitz 2026-06-25 20:38:56 UTC

This was fixed a while ago.