| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| usb_8dev_start_xmit in drivers/net/can/usb/usb_8dev.c in the Linux kernel through 5.17.1 has a double free. |
| Expat (aka libexpat) before 2.4.4 has a signed integer overflow in XML_GetBuffer, for configurations with a nonzero XML_CONTEXT_BYTES. |
| valid.c in libxml2 before 2.9.13 has a use-after-free of ID and IDREF attributes. |
| Processor optimization removal or modification of security-critical code for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. |
| The OPENSSL_LH_flush() function, which empties a hash table, contains a bug that breaks reuse of the memory occuppied by the removed hash table entries. This function is used when decoding certificates or keys. If a long lived process periodically decodes certificates or keys its memory usage will expand without bounds and the process might be terminated by the operating system causing a denial of service. Also traversing the empty hash table entries will take increasingly more time. Typically such long lived processes might be TLS clients or TLS servers configured to accept client certificate authentication. The function was added in the OpenSSL 3.0 version thus older releases are not affected by the issue. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2). |
| The function `OCSP_basic_verify` verifies the signer certificate on an OCSP response. In the case where the (non-default) flag OCSP_NOCHECKS is used then the response will be positive (meaning a successful verification) even in the case where the response signing certificate fails to verify. It is anticipated that most users of `OCSP_basic_verify` will not use the OCSP_NOCHECKS flag. In this case the `OCSP_basic_verify` function will return a negative value (indicating a fatal error) in the case of a certificate verification failure. The normal expected return value in this case would be 0. This issue also impacts the command line OpenSSL "ocsp" application. When verifying an ocsp response with the "-no_cert_checks" option the command line application will report that the verification is successful even though it has in fact failed. In this case the incorrect successful response will also be accompanied by error messages showing the failure and contradicting the apparently successful result. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2). |
| In doProlog in xmlparse.c in Expat (aka libexpat) before 2.4.3, an integer overflow exists for m_groupSize. |
| In Expat (aka libexpat) before 2.4.3, a left shift by 29 (or more) places in the storeAtts function in xmlparse.c can lead to realloc misbehavior (e.g., allocating too few bytes, or only freeing memory). |
| Improper access control for some 3rd Generation Intel(R) Xeon(R) Scalable Processors before BIOS version MR7, may allow a local attacker to potentially enable information disclosure via local access. |
| Null pointer dereference in subsystem for Intel(R) AMT before versions 15.0.35 may allow an authenticated user to potentially enable denial of service via network access. |
| Out-of-bounds write in the BIOS firmware for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege via local access. |
| Improper input validation in the firmware for some Intel(R) Processors may allow an authenticated user to potentially enable an escalation of privilege via local access. |
| Improper initialization of shared resources in some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. |
| Insufficient control flow management in some Intel(R) Processors may allow an authenticated user to potentially enable a denial of service via local access. |
| Improper initialization in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via physical access. |
| Improper access control in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via physical access. |
| Improper initialization in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via physical access. |
| Out-of-bounds read in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable an escalation of privilege via local access. |
| Pointer issues in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable an escalation of privilege via local access. |
| Out-of-bounds write in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable an escalation of privilege via local access. |
