CVE Tools

CVE-2026-0861

Integer overflow in memalign leads to heap corruption

Public exploit available. Not confirmed exploited in the wild yet. A vendor fix is available.

Published Updated Sources: CVE.org, NVD, BDU

What to do

The vendor has published a fix. Version details are below where the sources state them.

What it is

From the CVE record

Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc) in the GNU C Library version 2.30 to 2.42 may result in an integer overflow, which could consequently result in a heap corruption. Note that the attacker must have control over both, the size as well as the alignment arguments of the memalign function to be able to exploit this. The size parameter must be close enough to PTRDIFF_MAX so as to overflow size_t along with the large alignment argument. This limits the malicious inputs for the alignment for memalign to the range [1<<62+ 1, 1<<63] and exactly 1<<63 for posix_memalign and aligned_alloc. Typically the alignment argument passed to such functions is a known constrained quantity (e.g. page size, block size, struct sizes) and is not attacker controlled, because of which this may not be easily exploitable in practice. An application bug could potentially result in the input alignment being too large, e.g. due to a different buffer overflow or integer overflow in the application or its dependent libraries, but that is again an uncommon usage pattern given typical sources of alignments.

In plain language

No plain-language summary for this CVE yet.

Exploitation

Where each signal puts this CVE on the scale from published to confirmed exploited.

EPSS31st
Public exploit
CISA KEV

Not in the catalog. CISA has not confirmed exploitation.

Public exploits

1 source with a proof of concept or module.

Exploit links, PoCs and Metasploit modules after sign-in
EPSS

0.4% chance of exploitation activity in the next 30 days, which ranks it in the 31st percentile of scored CVEs.

Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.

Lifecycle

The patch came 31 days before any public exploit.

  1. OpenVAS check added
  2. Public exploit / PoCsource: other
  3. Patch availablerecord updated
  4. Publishedweakness classified, att&ck mapped

Affected products

Technical detail

CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Scored 8.4 by NVD.

How it is reached

  • Attack Vector LocalRequires local access to the vulnerable system (e.g. local login, malicious file)
  • Attack Complexity LowNo special conditions — the attack can be reliably reproduced
  • Privileges Required NoneNo authentication required — anyone can exploit this
  • User Interaction NoneNo user interaction needed — fully automated exploitation

Scope

  • Scope UnchangedImpact is limited to the vulnerable component itself

Impact if exploited

  • Confidentiality HighTotal information disclosure — all data in the component is compromised
  • Integrity HighTotal loss of integrity — attacker can modify any data in the component
  • Availability HighTotal denial of service — the component is completely unavailable

Weaknesses

ATT&CK techniques

Mapped from the weaknesses above (CWE to ATT&CK), not observed in attacks.

Sources

Watch the software you run.

My Stack ranks new CVEs for your products by real-world exploitation, so the next serious one reaches you without reading every advisory.

We'll flag the next CVE, public exploit or patch for Red Hat Inc., not every advisory. This one: public exploit.

We use analytics cookies to see which pages and articles actually help people. Decline and none of them run — the site works the same. What we store