If an X.509 certificate contains a malformed policy constraint and policy processing is enabled, then a write lock will be taken twice recursively. On some operating systems (most widely: Windows) this results in a denial of service when the affected process hangs. Policy processing being enabled on a publicly facing server is not considered to be a common setup.
Policy processing is enabled by passing the -policy argument to the command line utilities or by calling the X509_VERIFY_PARAM_set1_policies() function.
Update (31 March 2023): The description of the policy processing enablement was corrected based on CVE-2023-0466.
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Openssl | Openssl | 3.0.0 (including) | 3.0.7 (including) |
| Edk2 | Ubuntu | trusty | * |
| Edk2 | Ubuntu | xenial | * |
| Nodejs | Ubuntu | trusty | * |
| Openssl | Ubuntu | devel | * |
| Openssl | Ubuntu | fips-preview/jammy | * |
| Openssl | Ubuntu | fips-updates/jammy | * |
| Openssl | Ubuntu | jammy | * |
| Openssl | Ubuntu | kinetic | * |
| Openssl | Ubuntu | lunar | * |
| Openssl | Ubuntu | mantic | * |
| Openssl | Ubuntu | noble | * |
| Openssl | Ubuntu | oracular | * |
| Openssl | Ubuntu | upstream | * |
Locking is a type of synchronization behavior that ensures that multiple independently-operating processes or threads do not interfere with each other when accessing the same resource. All processes/threads are expected to follow the same steps for locking. If these steps are not followed precisely - or if no locking is done at all - then another process/thread could modify the shared resource in a way that is not visible or predictable to the original process. This can lead to data or memory corruption, denial of service, etc.