Approved changes feed: RSS · Atom
cpe:2.3:a:gnu:glibc:*:*:*:*:*:*:x86:*
part: a version: * update: *
| Vendor | Gnu (575dd98a-a14a-5d9e-a2eb-97d38d86fcb9) |
|---|---|
| Product | Glibc (b8610c0d-6ad8-566c-b276-03b23ae99324) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | * |
| Target hardware | x86 |
| Other | * |
| Notes | Imported from gcve-enriched-dumps CVE data |
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
| No PURL mappings for this CPE yet. | ||
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2020-29573 |
vulnerable | 2026-06-08 05:24:58.436838 |
Details available
sysdeps/i386/ldbl2mpn.c in the GNU C Library (aka glibc or libc6) before 2.23 on x86 targets has a stack-based buffer overflow if the input to any of the printf family of functions is an 80-bit long double with a non-canonical bit pattern, as seen when passing a \x00\x04\x00\x00\x00\x00\x00\x00\x00\x04 value to sprintf. NOTE: the issue does not affect glibc by default in 2016 or later (i.e., 2.23 or later) because of commits made in 2015 for inlining of C99 math functions through use of GCC built-ins. In other words, the reference to 2.23 is intentional despite the mention of "Fixed for glibc 2.33" in the 26649 reference.
Published: 2020-12-05T23:18:58.000Z
Updated: 2024-08-04T16:55:10.367Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2019-7309 |
vulnerable | 2026-06-08 05:14:14.232484 |
Details available
In the GNU C Library (aka glibc or libc6) through 2.29, the memcmp function for the x32 architecture can incorrectly return zero (indicating that the inputs are equal) because the RDX most significant bit is mishandled.
Published: 2019-02-03T02:00:00.000Z
Updated: 2024-08-04T20:46:46.043Z |
Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.