Bug 2515431 - stap always fails to sign modules with MOK due to mismatched SHA1 vs SHA256 fingerprints
Summary: stap always fails to sign modules with MOK due to mismatched SHA1 vs SHA256 f...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemtap
Version: 44
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Martin Cermak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-08-13 16:20 UTC by Daniel Berrangé
Modified: 2026-08-21 05:19 UTC (History)
5 users (show)

Fixed In Version: systemtap-5.5-2.fc44
Clone Of:
Environment:
Last Closed: 2026-08-21 05:19:43 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Daniel Berrangé 2026-08-13 16:20:34 UTC
ANy attempt to use stap --sign-module always fails

# stap --sign-module /home/berrange/src/virt/libvirt/examples/systemtap/qemu-monitor.stp  
....+..+...+...+.+...+..+.+...+.........+++++++++++++++++++++++++++++++++++++++++++++*..+....+.....+................+.........+...+..+...+............+......+......+..........+...+..+......+....+..............+....+..+.+...+......+........+...+...+.......+..+...+.........+.+...+.....+.+.....+...............+.+..+...+...............+...+.......+..+.+..+....+...+..+...+...+++++++++++++++++++++++++++++++++++++++++++++*..+......+...........+............+..........+..................+..+.............+........+.+......+...+..+.........+..........+...+++++
....+...+...+.....+...+....+..+..................+.+.....+.+...+..+...+...+.......+......+............+.................+...............+...+.............+......+++++++++++++++++++++++++++++++++++++++++++++*......+...+...+..+.+..+.......+..+..........+.........+......+.....+.+........+....+...........+....+........+....+...........+....+......+++++++++++++++++++++++++++++++++++++++++++++*...+...+..........+........+.......+...+.....+.........+...+.+......+.....+.+..............+.+..+..........+...+........+.........+..........+...........+.+......+.....+............+.+..............+...+....+...+........+....+...+...........+....+...+..+.+......+...+..+..........+.....................+..+.+...............+.........+..+.+..+..........+..+.............+........+.........+....+..+...+..........+..+....+........+.+...........+.+..+.......+.............................................+...+......+..............+...+...+.+........+......+..........+..+.......+...+++++
-----
Running sign-file failed
There is no machine owner key (MOK) in common with this system.
Use the following command to import a MOK into this system, then reboot:

	# sudo mokutil --import /root/.systemtap/ssl/server/moks/55:07:0d:ca:39:42:8a:34:71:c4:46:b2:3f:80:6c:fb:e1:fd:94:ad:20:35:dc:03:e0:c5:0b:3c:eb:d8:c2:3c/signing_key.x509


I follow that mokutil instruction, reboot, enroll the key, and retry stap and the same happens. it just creates yet another new key

The code logic is basically broken.

In systemtap_session::get_mok_info() it runs 'mokutil --list-enrolled' and matches with

	if (! regexp_match(line, "^(SHA1|SHA256) Fingerprint: ([0-9a-f:]+)$", matches))

mokutil --list-enrolled only prints out the SHA1 fingerprint

# mokutil --list-enrolled  | grep ^SHA
SHA1 Fingerprint: 2b:b0:10:e2:4d:94:c6:32:24:58:89:ba:aa:9e:d0:f3:d5:ef:1f:68
SHA1 Fingerprint: 92:bc:29:e3:43:28:5f:d6:35:1b:1a:0a:da:66:32:46:ec:90:57:f9
SHA1 Fingerprint: cc:d0:fa:f5:36:95:c9:6d:af:fb:21:77:66:a0:e5:1b:35:4a:21:42
SHA1 Fingerprint: aa:52:00:6e:e7:fb:b1:cc:be:b8:00:d0:44:69:7d:23:91:ce:88:34


meanwhile the code which stap created the MOK with in generate_mok() calls read_cert_info_from_file () to get the fingerprint.

read_cert_info_from_file unconditionally uses the SHA256 digest

  rv = PK11_HashBuf(SEC_OID_SHA256, fingerprint_buf, derCert.data, derCert.len);

With stap creating files named based on the SHA256 digest, but trying to read files named based on the SHA1 digest, this will never work.


Reproducible: Always

Steps to Reproduce:
1. Boot with secure boot enabled
2. stap --sign-module anything.stp

Actual Results:
Running sign-file failed
There is no machine owner key (MOK) in common with this system.
Use the following command to import a MOK into this system, then reboot:
....

Expected Results:
Finds the already enrolled key and uses it

Comment 1 Martin Cermak 2026-08-13 16:28:09 UTC
This is fixed in upstream commit 41b6fa81922e2c7ba6a19f769167160b98e42bd1 I believe. systemtap-5.5-1.fc44 comes from 2026-05-01 and doesn't have this fix.

Comment 2 Daniel Berrangé 2026-08-13 16:41:11 UTC
(In reply to Martin Cermak from comment #1)
> This is fixed in upstream commit 41b6fa81922e2c7ba6a19f769167160b98e42bd1 I
> believe. systemtap-5.5-1.fc44 comes from 2026-05-01 and doesn't have this
> fix.

Indeed, rebuilding with that commit added makes it work. Please can we get that cherry-picked into 44 or rebased to newer version as you prefer.

Comment 3 Fedora Update System 2026-08-13 17:30:56 UTC
FEDORA-2026-36fad44d85 (systemtap-5.5-2.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-36fad44d85

Comment 4 Martin Cermak 2026-08-13 17:34:12 UTC
( FTR: a F43 update was also created: https://bodhi.fedoraproject.org/updates/FEDORA-2026-fbf0d10791 )

Comment 5 Fedora Update System 2026-08-14 01:02:47 UTC
FEDORA-2026-36fad44d85 has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-36fad44d85`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-36fad44d85

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 6 Fedora Update System 2026-08-21 05:19:43 UTC
FEDORA-2026-36fad44d85 (systemtap-5.5-2.fc44) has been pushed to the Fedora 44 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.