GitHub Security Advisory: GHSA-v432-7f47-9g94
Package: PostQuantum-Feldman-VSS (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: <= 0.7.6b0
Patched in: 0.7.7b0

Summary: PostQuantum-Feldman-VSS'S Dependency Vulnerability in gmpy2 Leading to Interpreter Crash

Details:
**Description:**

PostQuantum-Feldman-VSS, a Python library implementing Feldman's Verifiable Secret Sharing scheme with post-quantum security, was vulnerable to denial-of-service attacks in versions up to and including 0.7.6b0.  This vulnerability stems from the library's reliance on the `gmpy2` library for arbitrary-precision arithmetic.  `gmpy2`, in turn, depends on the GNU Multiple Precision Arithmetic Library (GMP). GMP, by design, terminates the process when it cannot allocate memory.  An attacker could exploit this by providing carefully crafted inputs that cause `gmpy2` to attempt to allocate extremely large amounts of memory, leading to a crash of the Python interpreter and thus a denial of service.

**Vulnerability Details:**

The core issue lies in the behavior of GMP (and thus, `gmpy2`) when memory allocation fails.  Instead of raising a standard Python exception that could be caught and handled, GMP terminates the entire process. This behavior is documented in the GMP and gmpy2 documentation:

*   **GMP Memory Management:** [https://gmplib.org/manual/Memory-Management](https://gmplib.org/manual/Memory-Management) (States that the default behavior is to terminate the program.)
*   **gmpy2 Overview:** [https://gmpy2.readthedocs.io/en/latest/overview.html](https://gmpy2.readthedocs.io/en/latest/overview.html) (Warns that `gmpy2` can crash the interpreter on memory allocation failure.)

Specific operations within the PostQuantum-Feldman-VSS library that were particularly vulnerable include:

*   **Large Exponentiation (`exp`, `secure_exp`):**  Exponentiation with very large bases or exponents can lead to extremely large results, consuming excessive memory.
*   **Multi-exponentiation (`efficient_multi_exp`):**  Similar to exponentiation, but with multiple bases and exponents, increasing the risk.
*   **Matrix Operations (`_secure_matrix_solve`):**  Large matrices used in polynomial reconstruction could lead to significant memory usage.
*   **Polynomial Evaluation (`_evaluate_polynomial`):** Evaluating polynomials with large coefficients or at large values of `x` could trigger excessive memory allocation.

**Mitigations in 0.8.0b2:**

Version 0.8.0b2 implements *significant mitigations* to greatly reduce the risk of this denial-of-service vulnerability.  These mitigations **do not** completely eliminate the underlying issue (as that would require changes to GMP itself), but they make successful exploitation *far* more difficult.  The mitigations include:

1.  **Memory Monitoring (`MemoryMonitor` class):**
    *   A new `MemoryMonitor` class is introduced to track estimated memory usage throughout the library's operations.
    *   This class allows setting a maximum memory limit (defaulting to 1024MB, but configurable).
    *   It provides methods to `check_allocation`, `allocate`, and `release` memory, raising a `MemoryError` if an operation would exceed the configured limit.

2.  **Memory Safety Checks (`check_memory_safety` function):**