Focus on newlib_project vulnerabilities and metrics.
Last updated: 08 Mar 2025, 23:25 UTC
This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with newlib_project. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.
For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.
Total newlib_project CVEs: 10
Earliest CVE date: 18 Mar 2020, 16:15 UTC
Latest CVE date: 20 Aug 2024, 15:15 UTC
Latest CVE reference: CVE-2024-30949
30-day Count (Rolling): 0
365-day Count (Rolling): 1
Calendar-based Variation
Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.
Month Variation (Calendar): 0%
Year Variation (Calendar): 0%
Month Growth Rate (30-day Rolling): 0.0%
Year Growth Rate (365-day Rolling): 0.0%
Average CVSS: 3.95
Max CVSS: 7.5
Critical CVEs (≥9): 0
| Range | Count |
|---|---|
| 0.0-3.9 | 1 |
| 4.0-6.9 | 8 |
| 7.0-8.9 | 1 |
| 9.0-10.0 | 0 |
These are the five CVEs with the highest CVSS scores for newlib_project, sorted by severity first and recency.
An issue in newlib v.4.3.0 allows an attacker to execute arbitrary code via the time unit scaling in the _gettimeofday function.
A flaw was found in newlib in versions prior to 4.0.0. Improper overflow validation in the memory allocation functions mEMALIGn, pvALLOc, nano_memalign, nano_valloc, nano_pvalloc could case an integer overflow, leading to an allocation of a small buffer and then to a heap-based buffer overflow.
In the __d2b function of the newlib libc library, all versions prior to 3.3.0 (see newlib/libc/stdlib/mprec.c), Balloc is used to allocate a big integer, however no check is performed to verify if the allocation succeeded or not. Accessing _x will trigger a null pointer dereference bug in case of a memory allocation failure.
In the __mdiff function of the newlib libc library, all versions prior to 3.3.0 (see newlib/libc/stdlib/mprec.c), Balloc is used to allocate big integers, however no check is performed to verify if the allocation succeeded or not. The access to _wds and _sign will trigger a null pointer dereference bug in case of a memory allocation failure.
In the __lshift function of the newlib libc library, all versions prior to 3.3.0 (see newlib/libc/stdlib/mprec.c), Balloc is used to allocate a big integer, however no check is performed to verify if the allocation succeeded or not. The access to b1 will trigger a null pointer dereference bug in case of a memory allocation failure.
In the __multiply function of the newlib libc library, all versions prior to 3.3.0 (see newlib/libc/stdlib/mprec.c), Balloc is used to allocate a big integer, however no check is performed to verify if the allocation succeeded or not. The access of _x[0] will trigger a null pointer dereference bug in case of a memory allocation failure.
In the __i2b function of the newlib libc library, all versions prior to 3.3.0 (see newlib/libc/stdlib/mprec.c), Balloc is used to allocate a big integer, however no check is performed to verify if the allocation succeeded or not. The access of _ x[0] will trigger a null pointer dereference bug in case of a memory allocation failure.
In the __multadd function of the newlib libc library, prior to versions 3.3.0 (see newlib/libc/stdlib/mprec.c), Balloc is used to allocate a big integer, however no check is performed to verify if the allocation succeeded or not. This will trigger a null pointer dereference bug in case of a memory allocation failure.
The _dtoa_r function of the newlib libc library, prior to version 3.3.0, performs multiple memory allocations without checking their return value. This could result in NULL pointer dereference.
The REENT_CHECK macro (see newlib/libc/include/sys/reent.h) as used by REENT_CHECK_TM, REENT_CHECK_MISC, REENT_CHECK_MP and other newlib macros in versions prior to 3.3.0, does not check for memory allocation problems when the DEBUG flag is unset (as is the case in production firmware builds).