Thanks — after further investigation, I think the distinction between the triggering condition and the regression being fixed was not clearly explained in my earlier SRU text.
The user-visible regression being addressed by this SRU is that applications using NSS/p11-kit PKCS#11 module enumeration (Chromium, QtWebEngine consumers, etc.) can terminate with SIGSEGV during OpenSC initialisation on Noble. The triggering condition is that `sc_openssl3_init()` fails during provider initialisation (observed in FIPS-enabled environments when the OpenSSL FIPS provider cannot be loaded). That failure itself is expected to propagate as a recoverable PKCS#11 module initialisation error. This is only an issue in Noble due to the addition of FIPS with the patch from LP: #2127205 The provider initialisation failure is not necessarily itself an OpenSC defect. The failure path can be triggered by incomplete or inconsistent FIPS environments, for example: * missing OpenSSL FIPS provider packages, * incomplete FIPS enablement, * invalid OpenSSL provider configuration, * or systems where FIPS mode is enabled but the provider cannot actually be loaded. The actual regression is that OpenSC’s cleanup path dereferences `ctx->reader_driver` before it has been initialised, causing a crash in `sc_release_context()` instead of returning failure cleanly. So the end-to-end user story being validated by this SRU is: * Applications that enumerate PKCS#11 modules through NSS/p11-kit should continue operating normally even if opensc-pkcs11 initialisation fails, rather than segfaulting. * PKCS#11 module initialisation failures should be handled gracefully and returned as recoverable errors. * Host applications should not terminate due to memory-unsafe cleanup inside OpenSC. The purpose of the FIPS-enabled configuration in the test case is therefore not to validate FIPS functionality itself, but to reliably exercise the failing initialisation path that currently triggers the invalid cleanup sequence. --- The mention of the "root cause" there is my bad on this one. There are several failure paths that this SRU does *not* touch on as I believe those to be user-configuration or package installation-related issues rather than a bug in OpenSC itself. This is purely to stop user-facing applications crashing out completely due to those other failure-path conditions. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2147395 Title: [SRU] opensc-pkcs11 (0.25.0~rc1-1ubuntu0.2) SIGSEGV in sc_release_context during PKCS#11 C_Initialize via p11-kit/NSS (Ubuntu 24.04) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/opensc/+bug/2147395/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
