Ce mail provient de l'extérieur, restons vigilants

=====================================================================

                            CERT-Renater

                Note d'Information No. 2026/VULN062
_____________________________________________________________________

DATE                : 22/01/2026

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running GNU C Library versions 2.30 up
                                  to and including 2.42.

=====================================================================
https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=advisories/GLIBC-SA-2026-0003;hb=HEAD
https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=advisories/GLIBC-SA-2026-0002;hb=HEAD
_____________________________________________________________________

wordexp with WRDE_REUSE and WRDE_APPEND may return uninitialized memory

Calling wordexp with WRDE_REUSE in conjunction with WRDE_APPEND in the
GNU C Library version 2.0 to version 2.42Â may cause the interface to
return uninitialized memory in the we_wordv member, which on subsequent
calls to wordfree may abort the process.

The implementation of WRDE_REUSE in conjunction with WRDE_APPEND fails
to clear the we_wordc member of the structure, and as such, when new
words are added internally, a leading we_wordc count number of entries
are skipped since they are assumed initialized.  These skipped entries
are not initialized, but are the contents of a realloc-expanded array of
pointers.  If the caller inspects the we_wordv array, it will
dereference invalid pointers and crash. If the caller calls wordfree,
the malloc implementation may detect the invalid pointers and abort the
process.  Calls to wordexp using WRDE_REUSE and WRDE_APPEND have never
worked correctly and thus the existence of applications that make use of
this feature is unlikely.

CVE-Id: CVE-2025-15281
Public-Date: 2026-01-20
Vulnerable-Commit: 8f2ece695d8822e9ecc63ecd157e90bf17a6fe65 (1.93-260)
Fix-Commit: 80cc58ea2de214f85b0a1d902a3b668ad2ecb302 (2.43)
Fix-Commit: cbf39c26b25801e9bc88499b4fd361ac172d4125 (2.42-51)
Fix-Commit: fb4db64a04ad6c96cd1fbb7e02eb59323b1f2ac2 (2.41-123)
Fix-Commit: 9fe8576664d43b87ca19401fb6a975e217e47623 (2.40-218)
Fix-Commit: ce65d944e38a20cb70af2a48a4b8aa5d8fabe1cc (2.39-288)
Fix-Commit: d5409a1be010699794264162c551ba60f05ee6c3 (2.38-214)
Fix-Commit: ff2b172803f6bbd897755d2ce83ec4323a1a15b3 (2.37-174)
Fix-Commit: e97cfe2293ed097eb3d0b4c18274d22855e65130 (2.36-246)
Fix-Commit: bb59339d02faebac534a87eea50c83c948f35b77 (2.35-401)
Fix-Commit: 2b656ff94d72f93c84d8da2e7c76456c1994f02e (2.34-527)
Fix-Commit: 1d8ed2067a8a5d162a07670d0d063429679f17a0 (2.33-277)
Fix-Commit: 3a56c4ee4ea49b8f2391a2d8d6220013c4160a79 (2.32-153)
Fix-Commit: 28eb5caf895ced5d895cb02757e109004a2d33e5 (2.31-167)
Reported-by: Vitaly Simonovich
_____________________________________________________________________


getnetbyaddr and getnetbyaddr_r leak stack contents to DNS resovler

Calling getnetbyaddr or getnetbyaddr_r with a configured nsswitch.conf
that specifies the library's DNS backend for networks and queries for a
zero-valued network in the GNU C Library version 2.0 to version 2.42
can leak stack contents to the configured DNS resolver.

A defect in the _nss_dns_getnetbyaddr_r function which implements
getnetbyaddr and getnetbyaddr_r in the dns-based network database can
pass stack contents unmodified to the configured DNS resolver as part of
the network DNS query when the network queried is the default network
i.e. net == 0x0.  This stack contents leaking in the query is considered
a loss of confidentiality for the host making the query.  Typically it
is rare to call these APIs with a net value of zero, and if an attacker
can control the net value it can only leak adjacent stack, and so loss
of confidentiality is spatially limited.  The leak might be used to
accelerate an ASLR bypass by knowing pointer values, but also requires
network adjacent access to snoop between the application and the
DNS server; making the attack complexity higher.

CVE-Id: CVE-2026-0915
Public-Date: 2026-01-15
Vulnerable-Commit: 5f0e6fc702296840d2daa39f83f6cb1e40073d58 (1.92-1)
Fix-Commit: e56ff82d5034ec66c6a78f517af6faa427f65b0b (2.43)
Fix-Commit: 453e6b8dbab935257eb0802b0c97bca6b67ba30e (2.42-50)
Fix-Commit: 15c9839a0b853f552b4ed9047841b6223f3c104d (2.41-122)
Fix-Commit: 329c775788b2c9ff3da774ccf59fba7b6b8ff08e (2.40-217)
Fix-Commit: 831f63b94ceb92fb14c0d1a7ddad35a0d1404c71 (2.39-287)
Fix-Commit: 49125ffc8e1674dc2a100dfdc5b78796f22e16f2 (2.38-213)
Fix-Commit: ddcaed5dfb05b2c1a6ea842fd6b643501365450a (2.37-173)
Fix-Commit: a6bf47887f24b2b394acb301a3189fda04bd4d4d (2.36-245)
Fix-Commit: 66f0cb057c9b4fb1249a5fec6ef4a63511a37899 (2.35-400)
Fix-Commit: 96863dee262225cfb79f9fe45e06fd188319c7b8 (2.34-526)
Fix-Commit: d210011f1536c8322157cbb4fe4229b35c834c08 (2.33-276)
Fix-Commit: 1bc1832cfc74c2a601220969f36e789a5e9f0ebe (2.32-152)
Reported-by: Igor Morgenstern, Aisle Research


=========================================================
+ CERT-RENATER        |    tel : 01-53-94-20-44         +
+ 23/25 Rue Daviel    |    fax : 01-53-94-20-41         +
+ 75013 Paris         |   email:cert@support.renater.fr +
=========================================================