Add advisory text for CVE-2026-0861

Explain the security issue and set context for the vulnerability to help
downstreams get a better understanding of the issue.

Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>

diff --git a/advisories/GLIBC-SA-2026-0001 b/advisories/GLIBC-SA-2026-0001
new file mode 100644 (file)
index 0000000..3e0ee3b
--- /dev/null
+++ b/advisories/GLIBC-SA-2026-0001
@@ -0,0 +1,41 @@
+Integer overflow in memalign leads to heap corruption
+
+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.
+
+CVE-Id: CVE-2026-0861
+Public-Date: 2026-01-14
+Vulnerable-Commit: 9bf8e29ca136094f73f69f725f15c51facc97206 (2.30)
+Fix-Commit: c9188d333717d3ceb7e3020011651f424f749f93 (2.43)
+Fix-Commit: 7f19ef14fbce095d4c77395e258320cad2ea2b28 (2.30-153)
+Fix-Commit: f18446d7b4a423090ee5e328c36b3c2a0f26041c (2.31-166)
+Fix-Commit: 8aef9e7a7af9565c0324b4ecb38b30dfa3782fd8 (2.32-151)
+Fix-Commit: 011293b4fd748cdd6f95874ba2b6aba9a3df8bff (2.33-275)
+Fix-Commit: 2c77e52108a58956c9f674b36e1f59a4e3fdcf4d (2.34-525)
+Fix-Commit: 499d1ccafccfe64df1b88deea2fa84d8180e8e8f (2.35-399)
+Fix-Commit: fb6b8822175769b5794fb6ea04f2895483a29b61 (2.36-244)
+Fix-Commit: 7b913d41a07836def826f2164c52541a9835f324 (2.37-172)
+Fix-Commit: 744b63026a29f7eedbbc8e3a01a7f48a6eb0a085 (2.38-212)
+Fix-Commit: fb22fd3f5b415dd4cd6f7b5741c2f0412374e242 (2.39-286)
+Fix-Commit: bfc4dd9e526eacf3017dd8864ba0848e9d045dd4 (2.40-216)
+Fix-Commit: 1e2c1ea4307197ccece0cda574bcfebf9080894c (2.41-121)
+Fix-Commit: b0ec8fb689df862171f0f78994a3bdeb51313545 (2.42-49)
+Reported-by: Igor Morgenstern, Aisle Research