** Description changed:
[ Impact ]
The libp11 SRU for LP #2158304 (0.4.12-1.1ubuntu1, in noble-updates
since 2026-08-06) backported a workaround that calls
ENGINE_set_default_string(engine, "PKEY_CRYPTO") in load_privkey(). It
is never undone, so once a key is loaded through the PKCS#11 engine,
that engine stays the process-wide default for RSA and EC for the life
of the process.
Later provider-path code then gets a legacy, engine-backed context:
EVP_PKEY_CTX_new_from_name(NULL, "RSA", NULL) succeeds but
EVP_PKEY_fromdata_init() fails with
error:03000096:digital envelope routines:fromdata_init:operation not
supported for this keytype
This breaks EAP-TLS with TPM-backed PKCS#11 keys: wpa_supplicant loads
the Wi-Fi key through the engine, and tpm2-pkcs11's tpm2-tss code then
fails its own unrelated RSA operation while authorising the same key.
The reporter downgraded to 0.4.12-1.1build2 to get back online.
Upstream confirmed the problem in OpenSC/libp11#676 and closed it
without a libp11-side fix: the obvious cleanup is not a reference-
counted inverse and would clobber registrations made elsewhere.
This upload drops the backported patch, restoring noble's pre-SRU
behaviour.
[ Test Plan ]
Reproducible with SoftHSM2; no hardware required.
1. sudo apt install softhsm2 opensc libengine-pkcs11-openssl build-
essential libssl-dev
2. Create a token and import an RSA key:
openssl req -x509 -newkey rsa:2048 -keyout k.pem -out c.pem -days 365
-nodes -subj "/CN=Test"
softhsm2-util --init-token --free --label test --so-pin 1234 --pin 1234
softhsm2-util --import k.pem --token test --label testkey --id 01 --pin
1234
3. Build a probe that loads a key through the engine, then does
unrelated provider-path RSA work, as tpm2-tss does internally:
- cat > probe.c <<'EOF'
- #include <stdio.h>
- #include <openssl/engine.h>
- #include <openssl/evp.h>
- int main(void) {
- ENGINE_load_builtin_engines();
- ENGINE *e = ENGINE_by_id("pkcs11");
- ENGINE_init(e);
- EVP_PKEY *k = ENGINE_load_private_key(e,
- "pkcs11:token=test;object=testkey;type=private;pin-value=1234",
NULL, NULL);
- printf("load=%s\n", k ? "OK" : "FAILED");
- EVP_PKEY_CTX *c = EVP_PKEY_CTX_new_from_name(NULL, "RSA", NULL);
- int rc = EVP_PKEY_fromdata_init(c);
- printf("fromdata_init=%d -> %s\n", rc, rc > 0 ? "CLEAN" : "POLLUTED");
- return rc > 0 ? 0 : 1;
- }
- EOF
- gcc -Wno-deprecated-declarations probe.c -o probe -lcrypto
+ cat > probe.c <<'EOF'
+ #include <stdio.h>
+ #include <openssl/engine.h>
+ #include <openssl/evp.h>
- 4. ./probe
+ int main(int argc, char **argv)
+ {
+ if (argc < 2) {
+ fprintf(stderr, "usage: %s <pkcs11-key-uri>\n", argv[0]);
+ return 2;
+ }
+ ENGINE_load_builtin_engines();
+ ENGINE *e = ENGINE_by_id("pkcs11");
+ if (!e || !ENGINE_init(e)) {
+ fprintf(stderr, "failed to load the pkcs11 engine\n");
+ return 2;
+ }
+ EVP_PKEY *k = ENGINE_load_private_key(e, argv[1], NULL, NULL);
+ printf("load=%s\n", k ? "OK" : "FAILED");
+ if (!k)
+ return 2;
+ EVP_PKEY_CTX *c = EVP_PKEY_CTX_new_from_name(NULL, "RSA", NULL);
+ int rc = EVP_PKEY_fromdata_init(c);
+ printf("fromdata_init=%d -> %s\n", rc, rc > 0 ? "CLEAN" : "POLLUTED");
+ return rc > 0 ? 0 : 1;
+ }
+ EOF
+ gcc -Wno-deprecated-declarations probe.c -o probe -lcrypto
+ 4. ./probe 'pkcs11:token=test;object=testkey;type=private;pin-
+ value=1234'
+
+ Any other PKCS#11 token works too, by passing its own key URI. With a
+ YubiHSM 2, for example:
+
+ XDG_CONFIG_HOME=$PWD/pkcs11-home
YUBIHSM_PKCS11_CONF=$PWD/yubihsm_pkcs11.conf ./probe
'pkcs11:id=%7c%ee;type=private;pin-value=0001password'
0.4.12-1.1ubuntu1: fromdata_init=-2 -> POLLUTED, and each key load prints
"Workaround for OpenSSL 3.0.13 30 Jan 2024 enabled" to stderr.
0.4.12-1.1ubuntu2: fromdata_init=1 -> CLEAN, no workaround message.
[ Where problems could occur ]
This upload reintroduces the segfault that 0.4.12-1.1ubuntu1 fixed:
signing through the OpenSSL PKCS#11 engine will again crash on noble's
OpenSSL 3.0.13, as reported in LP: #2158304, LP: #2119094, LP: #2067163
and LP: #2097330.
- Who is actually affected is unverified. Users signing via a PKCS#11
token may have silently picked up a working setup since 2026-08-06 and
would lose it on upgrade, possibly inside automated pipelines where it
surfaces as a crash rather than an error. But nobody has reported being
fixed by the SRU: LP #2119094's noble task is still Triaged with no
comment since 2026-05-19, and LP #2067163 and LP: #2097330 have had no
activity since they were filed. The only confirmed verification is my
own, with a YubiHSM 2. That exposure is real but unquantified, unlike
this regression, which has a named reporter and a confirmed workaround.
- The crash is conditional, which bounds the blast radius. OpenSSL
commit 2b74e75, present only in 3.0.12 and 3.0.13, clears the engine
binding on the key returned by ENGINE_load_private_key(), dropping
libp11's functional reference. Only applications that then release their
own reference before using the key take the count to zero and tear down
the PKCS#11 context while the key is in use: sbsign, sbvarsign,
osslsigncode, Apache mod_ssl. Applications holding their reference until
teardown are unaffected either way - the openssl CLI, wpa_supplicant,
libcurl, nginx, libpq.
- No automated test catches this, in either direction. Nothing in the
openssl suite signs with an engine-loaded key, and libp11's autopkgtest
signs through the openssl CLI, which holds its reference, so it passes
with the workaround present and removed. Proposed-migration will be
green whichever state noble is in. Verification has to be manual.
- This is only half the fix. It clears the regression by returning noble
to its pre-SRU state and relies on a follow-up openssl SRU to fix the
segfault at its source. If that upload is rejected or delayed, noble
stays in the crashing state rather than reaching the state in the last
two rows below. Accepted, not overlooked.
- The version goes up while the code goes back. 0.4.12-1.1ubuntu2
removes the only delta 0.4.12-1.1ubuntu1 added, so its binaries should
match 0.4.12-1.1build2. The archive build2 engine,
/usr/lib/<triplet>/engines-3/pkcs11.so, has md5
f8b19f8221e46fc26a6b2c48c6880517 - a cheap check that nothing unintended
crept in.
Verified with SoftHSM2 and a YubiHSM 2 (sbsign against an RSA-2048 token
key):
openssl 3.0.13-0ubuntu3.15 + libp11 0.4.12-1.1build2 sbsign exits 139, no
regression
openssl 3.0.13-0ubuntu3.15 + libp11 0.4.12-1.1ubuntu1 sbsign exits 0,
regression present
openssl 3.0.13-0ubuntu3.16 + libp11 0.4.12-1.1build2 sbsign exits 0, no
regression
openssl 3.0.13-0ubuntu3.16 + libp11 0.4.12-1.1ubuntu2 sbsign exits 0, no
regression
[ Other Info ]
- Regression introduced by libp11 0.4.12-1.1ubuntu1 (LP #2158304).
- Upstream discussion and the maintainer's recommendation:
OpenSC/libp11#676.
- Debian hit the same defect and fixed it in openssl, not libp11: Debian
bug #1074764, fixed in openssl 3.0.13-1~deb12u2 (bookworm, 2024-07-05)
by reverting the same commit.
- The planned openssl SRU backports
ad6cbe4b7f57a783a66a7ae883ea0d35ef5f82b6 (openssl-3.0 branch;
39ea78379826fa98e8dc8c0d2b07e2c17cd68380 on master), released upstream
in 3.0.14 and carried in every 3.0.x since.
[ Original report ]
- wpa_supplicant fails: "Esys_StartAuthSession: Could not create rsa key
(0x00070001)"
- EAP-TLS fails: "ENGINE: cannot load private key ... operation not supported
for this keytype"
- Affects TPM2-backed PKCS#11 certificates via opensc-pkcs11.so (STMicro TPM)
Workaround: downgrade to 0.4.12-1.1build2
Environment:
- Ubuntu 24.04 Noble, OpenSSL 3.0.13
- wpa_supplicant + NetworkManager EAP-TLS
- TPM2 (STMicro), tpm2-tss 4.0.1, opensc 0.25.0~rc1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2163152
Title:
[SRU] EAP-TLS Wi-Fi broken with TPM-backed PKCS#11 keys after upgrade
to 0.4.12-1.1ubuntu1
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libp11/+bug/2163152/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
