Hello,

The following security advisory has been published:

GLIBC-SA-2026-0015: ===================

Passing an effectively empty string to the ,ccs= syntax extension of the mode argument in the fopen function in the GNU C Library version 2.45 or earlier may result in a heap buffer overflow when the mode string input to the function is attacker controlled.

This usage pattern is not seen in applications in common GNU or Linux distributions and applications that process user-supplied values for ccs should not pass them through without validation.

CVE-Id: CVE-2026-18374 Public-Date: 2026-08-27 Vulnerable-Commit: 129d706d77587e4d6627cc1ebef9be0f7cbc65f0 Reported-by: AISLE in partnership with Red Hat CVSS: CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L - 4.9

Notes: ======

Published advisories are available directly in the project git repository: https://sourceware.org/git/?p=glibc.git;a=tree;f=advisories;hb=HEAD

Passing an effectively empty string to the ,ccs= syntax extension of the mode argument in the fopen function in the GNU C Library version 2.45 or earlier may result in a heap buffer overflow when the mode string input to the function is attacker controlled.

This usage pattern is not seen in applications in common GNU/Linux distributions and applications that process user-supplied values for ccs should not pass them through without validation.

Sean Whitton [21/Aug 2:33pm +01] wrote: Bas Alberts of the GitHub Security Lab discovered a local command execution vulnerability in GNU Emacs 30.2 onwards, and possibly earlier. This has been assigned CVE-2026-79992, with thanks to Marco Benatto.

-- Sean Whitton

GNU wget is vulnerable to denial of service in its FTP OPIE/S-KEY authentication functionality. The server-supplied sequence number from the FTP challenge line is used as an iteration count for an MD5 key-derivation loop without any upper bound validation. A malicious FTP server or a network attacker positioned to intercept FTP traffic can send a crafted OPIE challenge with a sequence number near INTMAX, causing wget to perform up to approximately 2.1 billion MD5 computations and suspend for some time. The --timeout option does not mitigate this because it applies only to network I/O, not CPU computation.

This issue was fixed in commit e9697d98e7249b0f68a6be040a4f3dcc5bc101fa

CVSS Base Score: medium

Affected versions: gzip 1.14 and earlier

Description: Out-of-bounds memory buffer access that can be triggered if a single gzip -d instance decompresses specially crafted LZW data followed by specially crafted LZH data.

Users are recommended to apply the following patch, or to install gzip 1.15 whenever it comes out:

--- gzip-1.14/unlzh.c 2024-08-09 15:06:03.000000000 -0700 +++ gzip-1.14-CVE-2026-41992/unlzh.c 2026-08-22 22:26:05.384251837 -0700 @@ -307,6 +307,12 @@ static void hufdecodestart () { + / Needed in case LEFT and RIGHT are reused from a previous + LZW decompression. It may be overkill to clear all of both + arrays, but nobody has had time to analyze this carefully. / + memzero (left, (2 NC - 1) sizeof left); + memzero (right, (2 NC - 1) sizeof right); + initgetbits(); blocksize = 0; } Credits: Thanks to Michał Majchrowicz and to Elias Hasas for reporting the problem and supplying fixes.

GNU Emacs before 31.0.91 contains an integer overflow in the PBM/PPM/PGM image loader that allows an attacker to leak heap memory contents by supplying a crafted image with large dimensions and an elevated max color index. The image loader multiplies image dimensions and channel count using signed integer arithmetic; for sufficiently large values, the result wraps to a negative number, bypassing the bounds check and causing the pixel reader to access heap memory past the end of the allocated buffer. The over-read contents are interpreted as pixel color values and rendered on screen.

On 8/19/26 23:09, Sam James wrote: Eshel Yaron has shared an arbitrary code execution bug in GNU Emacs exploitable upon opening an file. It affects >= Emacs 28.1.

The reporter has a writeup at https://eshelyaron.com/posts/2026-08-06-emacs-arbitrary-code-execution-returns.html. It's from the same reporter as CVE-2024-53920 [0].

Thread on emacs-devel: https://lists.gnu.org/archive/html/emacs-devel/2026-07/msg00453.html https://lists.gnu.org/archive/html/emacs-devel/2026-08/msg00000.html

There's a workaround patch available for Emacs 31 (https://cgit.git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-31&id=8466eb44991707d128110bdc549fad14c8e1d61e) while on master it apparently had a bigger rework (https://cgit.git.savannah.gnu.org/cgit/emacs.git/commit/?id=c1337758a6c00e22e2a685e0556068fd73fa9a54).

In Gentoo, we backported the fix [1] down to 28.2.

[0] https://www.openwall.com/lists/oss-security/2025/02/26/2 [1] https://bugs.gentoo.org/980616

thanks, sam Disabling file-local variables seems to be an alternative mitigation, and the one I recommend. I would not be surprised if LLMs start popping out lots of 0day exploits in Emacs. -- Sincerely, Demi Marie Obenour (she/her/hers)

Eshel Yaron has shared an arbitrary code execution bug in GNU Emacs exploitable upon opening an file. It affects >= Emacs 28.1.

The reporter has a writeup at https://eshelyaron.com/posts/2026-08-06-emacs-arbitrary-code-execution-returns.html. It's from the same reporter as CVE-2024-53920 [0].

Thread on emacs-devel: https://lists.gnu.org/archive/html/emacs-devel/2026-07/msg00453.html https://lists.gnu.org/archive/html/emacs-devel/2026-08/msg00000.html

There's a workaround patch available for Emacs 31 (https://cgit.git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-31&id=8466eb44991707d128110bdc549fad14c8e1d61e) while on master it apparently had a bigger rework (https://cgit.git.savannah.gnu.org/cgit/emacs.git/commit/?id=c1337758a6c00e22e2a685e0556068fd73fa9a54).

In Gentoo, we backported the fix [1] down to 28.2.

[0] https://www.openwall.com/lists/oss-security/2025/02/26/2 [1] https://bugs.gentoo.org/980616

thanks, sam

The ISO-2022 encoding module used a stack buffer sized to MBLENMAX (6 bytes) for intermediate character output. Some ISO-2022 variants can require up to 10 bytes per character, in which case conversions can trigger a stack buffer overflow of up to four bytes.

An application that uses iconv(3) to convert untrusted input to or from one of the affected encodings may be vulnerable to buffer overflows if it uses one of the affected encoding modules.

Several encoding modules, including HZ, UTF-7, VIQR, and ZW, did not properly check the size of the caller-supplied output buffer before writing converted characters.

An application that uses iconv(3) to convert untrusted input to or from one of the affected encodings may be vulnerable to buffer overflows if it uses one of the affected encoding modules.

Hi Collin,

Thank you very much for the smooth and professional collaboration on this issue, and glad to see CVE-2026-19720 assigned.

Best regards,

Tristan Madani // Talence Security

Le sam. 15 août 2026 à 05:16, Collin Funk <collin.funk1 () gmail com> a écrit : Collin Funk <collin.funk1 () gmail com> writes: Timeline

2026-07-02: Report sent to inetutils-security () gnu org 2026-07-02: I (Collin Funk) acknowledged the report and asked a few questions regarding the issue. 2026-07-04: Tristan answered those questions. 2026-07-06: I reproduced the issue updated Tristan with a planned timeline for the fix and CVE assignment. 2026-07-08: Tristan agreed to the timeline and offered to review the patch. 2026-07-11: I wrote the patch and sent it to Tristan. 2026-07-15: Tristan confirmed the patch worked as expected. 2026-07-16: Private mail to distros mailing list along with the patch. 2026-07-24: I wrote this report and sent it to oss-security.

Note that I also requested a CVE when emailing distros, but haven't heard back. I'll probably reach out privately to a CNA in a bit, and will update here once one is assigned. Red Hat assigned CVE-2026-19720 to this issue yesterday, 2028-08-13.

Collin

Collin Funk <collin.funk1 () gmail com> writes: Timeline

2026-07-02: Report sent to inetutils-security () gnu org 2026-07-02: I (Collin Funk) acknowledged the report and asked a few questions regarding the issue. 2026-07-04: Tristan answered those questions. 2026-07-06: I reproduced the issue updated Tristan with a planned timeline for the fix and CVE assignment. 2026-07-08: Tristan agreed to the timeline and offered to review the patch. 2026-07-11: I wrote the patch and sent it to Tristan. 2026-07-15: Tristan confirmed the patch worked as expected. 2026-07-16: Private mail to distros mailing list along with the patch. 2026-07-24: I wrote this report and sent it to oss-security.

Note that I also requested a CVE when emailing distros, but haven't heard back. I'll probably reach out privately to a CNA in a bit, and will update here once one is assigned. Red Hat assigned CVE-2026-19720 to this issue yesterday, 2028-08-13.

Collin

Calling wordexp with WRDEAPPEND in the GNU C Library version 2.0 to version 2.43 can cause the interface to return invalid memory in the wewordv member, which on subsequent calls to wordfree may abort the process.

GNU cpio is vulnerable to improper encoding or escaping of output in its archive member listing functionality. When listing archive members via cpio -it, member names are printed directly to output without quoting or escaping. An attacker can craft a cpio archive containing member names with embedded newline characters or ANSI escape sequences, causing forged listing entries or terminal control sequence injection when the listing is displayed.

GNU cpio is vulnerable to an uncontrolled memory allocation in the makepath function at src/makepath.c. The function uses alloca to allocate stack memory based on the length of argpath, which is derived from an archive-controlled pathname during extraction. A malicious cpio archive containing a sufficiently long nested pathname causes an unbounded stack allocation, resulting in a stack overflow and crash of the cpio process. An attacker who can supply a crafted cpio archive to a victim who extracts it can cause a denial of service.

GNU cpio contains a Path Traversal vulnerability in its tar archive extraction functionality. When extracting a tar archive in copy-in mode with the --no-absolute-filenames option, the extracted file name is normalized but the tar hard-link target is passed to the linktoname function without equivalent sanitization before calling link function. A tar archive provided by an attacker, containing a hard-link entry whose linkname is set to an absolute path outside the extraction directory, can cause cpio to create a hard link to an existing file outside the intended extraction directory, breaking the expected guarantee of --no-absolute-filenames and allowing archive-controlled linkage to external files.

GNU Emacs for Android is vulnerable to an integer overflow in the sfntreadcmapformat12() function in src/sfnt.c. When processing a crafted TrueType font file, an unguarded addition in the xmalloc allocation call wraps around on 32-bit builds, causing a heap buffer overflow write. An attacker can deliver a malicious font file via email, EWW (Emacs Web Wowser), or documents with custom faces, causing Emacs to load it. This results in heap memory corruption that can lead to code execution.

This issue was fixed in commit c4e20777c26548722a37b03db93243e83a0d6188

GNU Emacs for Android contains an off-by-one error in the gvar table parser in src/sfnt.c. The shared-coordinate index boundary check in sfntvarysimpleglyph() and sfntvarycompoundglyph() uses a strict greater-than comparison instead of greater-than-or-equal, allowing a crafted TrueType variable font to bypass the check and trigger a heap-based out-of-bounds read via memcpy. An attacker can deliver a malicious font file via email, EWW (Emacs Web Wowser), or documents with custom faces, causing Emacs to load it. This exposes heap memory contents which can be later used to defeat ASLR.

This issue was fixed in commit 95ab9ef627b212d74d321c5bbb5b56a1be7b9fbe

A flaw was found in GNU tar. The --one-top-level option is intended to confine extraction under a designated directory, but hardlink targets from the archive are not confined the same way and are resolved relative to the extraction working directory (or the directory given with -C). A crafted archive can create hardlinks inside the --one-top-level directory that point to files outside it. If a suitable symbolic link already exists under the extraction working directory, hardlinking to that symlink can bypass tar's usual symlink-based path protections and allow writing outside the intended top-level directory during a single extraction. Users who rely on --one-top-level as a security boundary when extracting untrusted archives may be affected.

A TOCTOU (Time-of-Check Time-of-Use) vulnerability in GNU tar's incremental dumpdir 'X' rename handling allows a local attacker with write access to a directory being backed up to influence the restore process if the attacker has access to the system where the restore is being performed. During restoration, files or directories may be created, renamed or overwritten outside the intended extraction directory. This could lead to unauthorized file modification or, in some cases, privilege escalation. Exploitation does not require the attacker to modify or craft the archive, and standard backup and restore workflows—including extracting into a newly created directory without using the -P option do not mitigate the issue.

A TOCTOU (Time-of-Check Time-of-Use) vulnerability in GNU tar's incremental dumpdir 'X' rename handling allows a local attacker with write access to a directory being backed up to influence the restore process if the attacker has access to the system where the restore is being performed. During restoration, files or directories may be created, renamed or overwritten outside the intended extraction directory. This could lead to unauthorized file modification or, in some cases, privilege escalation. Exploitation does not require the attacker to modify or craft the archive, and standard backup and restore workflows—including extracting into a newly created directory without using the -P option do not mitigate the issue.

Arbitrary Output Location Change in GNU Bison

Arbitrary Command Execution in GNU Bison

This is a vulnerability report sent to us through https://issues.redhat.com/browse/PSIRTSUPT-17918 and was created using the PoC auto-triage agents. It contains hints on the vulnerability extracted by the IA and the full report. ALWAYS review it before any action. Once working on this, don't forget to also update the JSM ticket.

Multiple Use-After-Free vulnerabilities were found in the addarchiveelement function in ld/ldmain.c of the GNU linker (ld), a component of binutils. The root cause is that pluginmaybeclaim() in ld/plugin.c frees the original BFD object via bfdclose/bfddeletebfd when entry->thebfd->myarchive == NULL, but the caller retains both the original abfd parameter and a shallow copy (originput.thebfd) as dangling pointers. These dangling pointers are subsequently dereferenced at three distinct locations in addarchiveelement:

1. Line ~1442: accessing abfd->myarchive via bfdusrdata(abfd->myarchive) 2. Line ~1493: multiple accesses to abfd and abfd->myarchive in a conditional check and bfdgetfilename call 3. Line ~1525: dereferencing the shallow copy originput.thebfd->myarchive in trace/verbose logging

The vulnerability is triggered when LTO plugins are active (linkinfo.ltopluginactive is true) and the input object has abfd->myarchive == NULL, which is a valid state for standalone object files. Red Hat builds binutils with --enable-plugins and --enable-lto, confirming the vulnerable code path is compiled in and reachable.

An attacker who can supply a crafted object or archive file to a build process using LTO-enabled linking could exploit this flaw to cause a denial of service (linker crash via segmentation fault). Arbitrary code execution is theoretically possible through heap manipulation but is substantially mitigated by hardening measures including stack protector, FORTIFYSOURCE, ASLR, and PIE.

The attack surface is limited to build-time environments — the linker is a development tool not exposed in production runtime. The most realistic exploitation scenario is a supply chain attack introducing a crafted object file as a build dependency in CI/CD pipelines or development environments.

This is a vulnerability report sent to us through https://issues.redhat.com/browse/PSIRTSUPT-18741 and was created using the PoC auto-triage agents. It contains hints on the vulnerability extracted by the IA and the full report. ALWAYS review it before any action. Once working on this, don't forget to also update the JSM ticket.

An out-of-bounds write vulnerability was found in the BFD library's DLX ELF backend (bfd/elf32-dlx.c) in GNU binutils. The dlxrtypetohowto() function maps ELF relocation types to internal howto structures but fails to perform adequate bounds checking on attacker-controlled relocation type values (via ELF32RTYPE(rinfo)) before indexing into the dlxelfhowtotable[] array. The DLX relocation type number space is non-contiguous (basic types 0-6, extended types at 0x10000+), but the default case in the switch statement allows arbitrary index values to reach the array access.

A specially crafted ELF/DLX object file can trigger this out-of-bounds write when processed by any BFD-consuming tool (objdump, readelf, strip, ld, nm, objcopy). The vulnerability has been demonstrated to achieve arbitrary code execution via a File Stream Oriented Programming (FSOP) attack against glibc FILE structures (stderr), redirecting control flow to system().

Attack scenarios include CI/CD pipelines performing automated binary analysis, developer workstations running objdump/readelf on untrusted binaries, automated security scanning or malware analysis tools invoking binutils, and package build systems processing third-party code.

Note: This vulnerability is only exploitable when binutils is built with the DLX backend enabled (typically via --enable-targets=all). Manual verification of Red Hat package build configurations is required to confirm affected product scope.

The "Security related changes" section below lists fixes for CVE-2026-4046, CVE-2026-4437, & CVE-2026-4438.

-------- Forwarded Message -------- Subject: The GNU C Library version 2.44 is now available Date: Sat, 25 Jul 2026 18:49:56 +0900 From: Andreas K. Huettel <dilfridge () gentoo org> Organization: Gentoo Linux To: libc-alpha () sourceware org, libc-announce () sourceware org, info-gnu () gnu org

The GNU C Library =================

The GNU C Library version 2.44 is now available.

The GNU C Library is used as the C library in the GNU system and in GNU/Linux systems, as well as many other systems that use Linux as the kernel.

The GNU C Library is primarily designed to be a portable and high performance C library. It follows all relevant standards including ISO C23 and POSIX.1-2024. It is also internationalized and has one of the most complete internationalization interfaces known. The GNU C Library website is at http://www.gnu.org/software/libc/

Packages for the 2.44 release may be downloaded from: http://ftpmirror.gnu.org/libc/ http://ftp.gnu.org/gnu/libc/

The mirror list is at http://www.gnu.org/order/ftp.html

Distributions are encouraged to track the release/ branches corresponding to the releases they are using. The release branches will be updated with conservative bug fixes and new features while retaining backwards compatibility.

NEWS for version 2.44 =====================

Major new features:

System-wide tunables can be applied using /etc/tunables.conf and running ldconfig. Specific tunable settings and the /etc/tunables.conf file format and path are not part of the stable library interfaces and may change between releases.

A new tunable, glibc.elf.thp, is added to map read-only segments with Transparent Huge Pages (THP) if THP is not disabled in the kernel. When glibc.elf.thp is set to 1, malloc uses the actual kernel THP mode instead of defaulting to madvise mode and madvisethp will stop issuing MADVHUGEPAGE if kernel THP mode is always.

The THP page size in malloc is capped to MAXTHPPAGESIZE. If the THP page size is above MAXTHPPAGESIZE, THP in malloc is disabled.

Additional optimized and correctly rounded mathematical functions have been imported from the CORE-MATH project, in particular cosh, sinh, and tanh.

Many additional improvements to existing functions have been synchronized from the CORE-MATH project.

For C++26, the assert macro is now variadic, allowing more complex arguments containing commas (which however still must evaluate to a single value).

The SVID error handling for cosh and sinh was moved to compatibility symbols, allowing improvements in performance.

Static PIE is now supported for arm--linux-gnueabi. It requires toolchain support to correctly set the expected linker options.

On AArch64 targets that support the Guarded Control Stack extension all GCS operations (including status, write on shadow stack, and push to shadow stack) are locked after enabling GCS with ENFORCED or OVERRIDE GCS policy. When a GCS operation is locked, a program cannot change this operation status via the prctl syscall. This prevents disabling or corrupting the GCS shadow stack during runtime.

On AArch64 targets, log, exp, sin, cas, sinh, cosh, asinh, acosh, atanh single and double precision special cases have been vectorized for SVE and AdvSIMD, and vector variants of powr have been added.

On RISC-V targets, vector extension optimized variants of memcmp, memccpy, memchr, memcpy, memmove, stpncpy, strcmp, strchr, strcpy, strncmp, strncpy, strlen, and strrchr have been added.

On PowerPC, memchr optimized for Power10 has been re-added.

Support for LoongArch32 has been added.

Pre-built ld.so.cache files can be installed with ldconfig.

A new locale has been added: hrxBR (Hunsrik language spoken in Brazil).

Deprecated and removed features, and other changes affecting compatibility:

Although malloc and related functions currently return pointers aligned to alignof (maxalignt), the documentation now says future versions of glibc may relax alignment requirements for small allocations. For example, a future malloc(1) might return a pointer with odd alignment, because no object of size 1 can have a fundamental alignment greater than 1.

The s390-linux-gnu (31bit) configuration is no longer supported.

The --enable-memory-tagging configure option has been removed. The corresponding AArch64-specific functionality that was previously activated by this flag has been removed as well.

The --enable-static-nss configure option has been removed. It had no effect on the build since the NSS reorganization in glibc 2.33; its only remaining behavior was to suppress the link-time warnings on the NSS interface functions in libc.a, which are now emitted unconditionally.

Security related changes:

The following CVEs were fixed in this release, details of which can be found in the advisories directory of the release tarball:

GLIBC-SA-2026-0005: gethostbyaddr and gethostbyaddrr may incorrectly handle DNS response (CVE-2026-4437)

GLIBC-SA-2026-0006: gethostbyaddr and gethostbyaddrr return invalid DNS hostnames (CVE-2026-4438)

GLIBC-SA-2026-0007: iconv crash due to assertion failure with untrusted input (CVE-2026-4046)

The following bugs were resolved with this release:

[2363] libc: EOPNOTSUPP and ENOTSUP in errno.h must be different, according to SUSv3 [3794] manual: iconv: //TRANSLIT and //IGNORE feature not documented [15792] dynamic-link: [arm] ARM dynamic linker should save/restore coprocessor registers [20331] libc: fts ignores errors from readdir() [20680] dynamic-link: ifunc resolver cannot access the thread pointer with static linking [22944] libc: fts cannot traverse paths which have a length longer than USHRTMAX [25257] libc: sotruss: fix error message for '--f' argument [25770] locale: newlocale memory leak in LOCPATH parsing and on error paths [27582] libc: x8664: IFUNC in static user programs may crash when built with -fstack-protector-all [28218] dynamic-link: ld.so: ifunc resolver calls a lazy PLT. When does it work? [28817] libc: static-pie ifunc resolver tls failure [28940] nss: nssdatabaseget doesn't check for allocation failure [30136] manual: Please document behaviour of iconv(3) when input is untranslatable [30304] nptl: nptl/tst-pthread-gdb-attach test fails with new libc shared library version [30769] malloc: malloctrim is not working correctly for arenas other than arena 0 [30976] dynamic-link: rtld: resolve ifunc relocations after JUMPSLOT/GLOBDAT/etc [30992] libc: alpha: setrlimit() with negative values besides RLIMINFINITY returns EPERM [31901] libc: elf/tst-glibc-hwcaps-prepend-cache fails on i686 [33226] math: math-vector-fortran.h vs not ffast-math [33626] libc: execvpe should skip inaccessible $PATH components [33650] build: abilist.awk doesn't handle unversioned defined symbols [33785] stdio: New streams are linked into global list before they are fully initialized [33848] build: Build fails at openat2.h, redefinition of 'struct openhow' [33882] libc: Recursion in nftw() causes stack overflow(CWE-674) [33904] build: error: 'vasprintfchk' undeclared here [33921] build: Building with Linux-7.0-rc1 errors on OPENTREECLONE [33935] stdio: IOwfiledoallocate not linked correctly when linking glibc statically [33980] locale: iconv: ibm139x trigger assertion error when converting to internal while lack enough room (CVE-2026-4046) [33985] build: ld: cannot find -lgccs: No such file or directory [33999] stdio: libio: potential dangling IOsavebase or memory leak in wgenops.c [34006] stdio: libio: inconsistent fmemopenwrite behavior on last \0 [34008] stdio: stdio-common: scanf %mc pattern will cause heap overflow when width > 1024 [34014] nss: gethostbyaddr and gethostbyaddrr may incorrectly handle DNS response [34015] nss: gethostbyaddr and gethostbyaddrr return invalid DNS hostnames [34019] stdio: libio: undefined behavior when setbuf on openmemstream [34033] network: resolv/nsprint.c: nssprintrrf TSIG path bypasses buflen and can overflow caller buffer [34064] dynamic-link: The unnecessary PTNOTE check in when loading a binary [34069] network: Buffer overread in nssprintrrf with corrupted RDATA field (CVE-2026-6238) [34070] hurd: Calling open ("/dev/tty/", ORDONLY) causes the program to segfault [34073] regex: regexec can mistakenly match with backrefs and the $ anchor [34079] dynamic-link: THP segment load aligns all PTLOAD segments to THP page size [34080] dynamic-link: Support THP segment load with THP enabled with madvise [34083] dynamic-link: getthpmode and getthpsize are called twice [34090] libc: wordexp WRDEAPPEND rollback restores stale wewordv, leading to invalid free in wordfree [34098] libc: Missing SUPPORTSTATICPIE in arm32 [34129] string: x86: Non-temporal memset unreachable on AMD Zen 3/4/5 [34144] libc: ld.so clobbers VFP registers during runtime linking [34154] network: Segfault in sockeq after resinit() returns -1, due to stale u.ext.nscount in resiclose [34156] dynamic-link: dlsym(RTLDDEFAULT, ...) from a constructor SIGSEGVs when tail-called [34164] dynamic-link: elf: IFUNC resolvers do not see static TLS initialization [34170] dynamic-link: elf: IFUNC resolver reading global- dynamic/TLSDESC thread variable crashes inside tlsgetaddr [34183] math: fma produces wrong results [34192] nptl: pthreadsetnamenp opens /proc/<tid>/comm with ORDWR instead of OWRONLY|OCLOEXEC [34196] libc: elf: static dlopen: pointer guard of the loaded ld.so/libc.so is left uninitialized [34197] dynamic-link: elf: Stack canary and pointer guard are recoverable from ATRANDOM (getauxval) [34205] libc: aarch64: SIGSEGV in tunablestrcmp in static-pie binaries run with a string tunable [34208] stdio: scanf not pushback after matching failure [34210] libc: elf/tst-glibc-hwcaps-prepend-cache fails on armv7a-unknown-linux-gnueabihf [34236] locale: Non-representable transliteration still causes iconv to exit with 1 if //TRANSLIT is specified [34289] network: nssprintrrf uses pclass, ptype internally [34311] build: THP tests failed to link [34347] libc: Incorrect trailing bitfield word of struct tcpinfo [34348] dynamic-link: FAIL: elf/tst-thp-1 if THP is disabled in kernel [34351] build: Random test failures [34355] build: [2.44 Regression] "make check -j7 subdirs=stdio-common" no longer works [34396] libc: sparc64-unknown-linux-gnu , Gentoo: >200 test failures, SIGILL in many binaries [34398] string: Truncated strncpy on s390x z900 ifunc variant

Release Notes =============

https://sourceware.org/glibc/wiki/Release/2.44

Contributors ============

This release was made possible by the contributions of many people. The maintainers are grateful to everyone who has contributed changes or bug reports. These include:

Adam Yi Adhemerval Zanella Alejandro Colomar Andreas K. Hüttel Andreas Schwab Arjun Shankar Aurelien Jarno Avinal Kumar Brian Jorgensen Carlos O'Donell Carlos Peón Costa Charlotte Mcmenamin Collin Funk Cosmina Dunca DJ Delorie Daan De Meyer Deng Jianbo Dev Jain Diego Nieto Cid Dmitry Kovalenko Dylan Fleming Etienne Brateau Fabian Rast Florian Weimer Frédéric Bérat Garccez George Hu H.J. Lu Jakub Jelinek Jiamei Xie Jiho Lee Jiri Stransky John David Anglin Jonathan Wakely Josef Johansson Joseph Myers Justus Winter Luca Boccassi Lucas Chollet Martin Coufal Matt Turner Michael Ford Michael Jeanson Michael Kelly Mike FABIAN Mike Kelly Muhammad Kamran Nicolas Boulenguez Paul Eggert Peter Bergner Peter Collingbourne Petr Menšík Pierre Blanchard Pino Toscano Pádraig Brady Richard Wild Rocket Ma RyotaSaito Sachin Monga Sajan Karumanchi Sam James Samuel Balazi Samuel Thibault Sana Kazi Sergey Kolosov Shamil Abdulaev Shengwen Cheng Siddhesh Poyarekar Stefan Liebler Thomas Daubney Tomasz Kamiński Uros Bizjak WANG Rui Weihong Ye Weixie Cui Wilco Dijkstra Xi Ruoyao Xiang Gao Yao Zihong Yunze Zhu Yury Khrustalev Zihong Yao mengqinggang xiejiamei zombie12138

We would like to call out the following and thank them for their tireless patch review:

Adhemerval Zanella Andreas K. Hüttel Arjun Shankar Aurelien Jarno caiyinyu Carlos O'Donell Collin Funk DJ Delorie Florian Weimer Frédéric Bérat Ganesh Gopalasubramanian H.J. Lu JiangNing Mathieu Desnoyers Paul Eggert Paul Zimmermann Peter Bergner Sam James Samuel Thibault Siddhesh Poyarekar Stefan Liebler Sunil K Pandey Wilco Dijkstra Yury Khrustalev

-- PD Dr. Andreas K. Hüttel dilfridge () gentoo org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge

GNU Inetutils Security Advisory: talkd buffer overflow with long DNS names

History

GNU Inetutils distributes a 'talkd' program, which uses the ntalk protocol to communicate over the network. Like much of GNU Inetutils, this implementation was derived from 4.4BSD sources. From what I can tell, the issue described in this email only applies to GNU Inetutils and was introduced by a change on 2001-10-25 [1]. The first release with that change was GNU inetutils-1.4.0, released on 2002-07-31. Regardless, I reported the issue privately to the distros mailing list on 2026-07-16, so other implementors could check.

Reproduction Steps

To construct the announcement message, 'talkd' looks up a client's domain name using its IP address and gethostbyaddr, which is typically a reverse DNS lookup. The issue occurs when it returns a domain name longer than around 200 characters. Here is the reproduction I shared privately on the distros list. Note that the steps vary depending on operating system, e.g., how 'inetd' starts:

$ echo 'ntalk dgram udp wait tty:tty /bin/talkd talkd' >> /etc/inetd.conf $ service inetd start $ printf '%s %s\n' <CLIENT-IP> $(yes | head -n 250 | tr -d '\n') >> /etc/hosts

Then, on the machine with <CLIENT-IP> run the following, where <HOST-IP> is the machine running talkd and <USER> is a user you are logged into:

$ talk <USER>@<CLIENT-IP>

If 'talkd' is affected, that should be enough to reproduce the issue. Using a FreeBSD machine with an unpatched GNU Inetutils 2.8 build with sanitizers disabled here is what I see:

$ cat /var/log/messages [...] Jul 16 22:10:55 freebsd inetd[15837]: /home/collin/inetutils/talkd/talkd[16090]: exited, signal 10 Jul 16 22:10:55 freebsd inetd[16091]: warning: /etc/hosts.allow, line 22: can't verify hostname: getaddrinfo(yyy..., AFINET) failed Jul 16 22:10:55 freebsd inetd[15837]: /home/collin/inetutils/talkd/talkd[16091]: exited, signal 10 Jul 16 22:10:55 freebsd inetd[16092]: warning: /etc/hosts.allow, line 22: can't verify hostname: getaddrinfo(yyy..., AFINET) failed Jul 16 22:10:55 freebsd inetd[15837]: /home/collin/inetutils/talkd/talkd[16092]: exited, signal 10 Jul 16 22:10:55 freebsd inetd[16093]: warning: /etc/hosts.allow, line 22: can't verify hostname: getaddrinfo(yyy..., AFINET) failed Jul 16 22:10:55 freebsd inetd[15837]: /home/collin/inetutils/talkd/talkd[16093]: exited, signal 10 Jul 16 22:10:55 freebsd inetd[15837]: ntalk/udp server failing (looping), service terminated Jul 16 22:10:55 freebsd kernel: pid 16023 (talkd), jid 0, uid 4: exited on signal 10 (no core dump - other error) Jul 16 22:10:55 freebsd kernel: pid 16024 (talkd), jid 0, uid 4: exited on signal 10 (no core dump - other error) Jul 16 22:10:55 freebsd kernel: pid 16025 (talkd), jid 0, uid 4: exited on signal 10 (no core dump - other error) Jul 16 22:10:55 freebsd kernel: pid 16026 (talkd), jid 0, uid 4: exited on signal 10 (no core dump - other error) Jul 16 22:10:55 freebsd kernel: pid 16027 (talkd), jid 0, uid 4: exited on signal 10 (no core dump - other error)

I.e., 'talkd' crashes with SIGBUS.

Workarounds

Don't use 'talkd' in 2026. There are much better programs for users to communicate nowadays. Interestingly, Debian removed the 'mesg' program from their util-linux package for this reason [2].

Using ACLs, the -a or --acl option, would also protect you [3]. Although, I am curious how often that option actually gets used...

Detailed Description

Here is a more detailed explanation of the issue, for reference. When GNU 'talkd' processes a request, it first verifies it against the configured ACLs. Triggering the issue requires the request not to be denied by the ACL [4]:

if (aclmatch (msg, sain) == ACLDENY) { / Code unnecessary for describing the issue removed... / return 0; }

The ACL mechanism [3] is not enabled by default, and likely very few people use it. Well, very few people use 'talkd' at all, for that matter.

If the message is an ANNOUNCE request, an announcement is sent to the terminal of the user that they are trying to contact [5]:

switch (msg->type) { case ANNOUNCE: doannounce (msg, rp); / ... / }

The announcement is not sent if 'mesg n' is in use:

$ mesg n; mesg; stat --format=%A tty is n crw-------

That is opposed to 'mesg y', which allows the issue to be triggered:

$ mesg y; mesg; stat --format=%A tty is y crw--w----

The relevant source code can be seen here [6]:

sprintf (ttypath, "%s/%s", PATHTTYPFX, request->rtty); rc = stat (ttypath, &st); free (ttypath); if (rc < 0 || (st.stmode & SIWGRP) == 0) return PERMISSIONDENIED; return printmesg (request->rtty, request, remotemachine);

This announcement contains the name of the host, as returned by gethostbyaddr(3) [7]:

hp = gethostbyaddr ((char ) &os2sinaddr (mp->ctladdr), sizeof (struct inaddr), AFINET);

Here is the format of that announcement message [8], where "yourmachine" is hp->hname, resulting from the above gethostbyaddr call:

Message from TalkDaemon@hismachine... talk: connection requested by yourname@yourmachine. talk: respond with: talk yourname@yourmachine

Each line ends in spaces up to the maximum line length plus two. The message also starts with an ASCII BEL, CR, LF, followed by a line full of spaces, and ends with a line full of spaces.

The issue is that the maximum line length is calculated using vsnprintf, which returns the number of bytes required to store the resulting string regardless of how many were actually written to the buffer [9]:

static void formatline (LINE lp, const char fmt, ...) { / Here lp->line[i] contains the line in the announcement string, and lp->size[i] contains the length of the line. / lp->size[i] = vsnprintf (lp->line[i], sizeof lp->line[i], fmt, ap); / We later pad each line "i" with spaces from lp->size[i] to lp->maxsize + 2. / lp->maxsize = MAX (lp->maxsize, lp->size[i]); / ... / }

These lines are then copied over to a 1283 (5 256 + 3) byte buffer [10] [11]:

#define NLINES 5 #define NCHARS 256

typedef struct { int ind; int maxsize; char line[NLINES][NCHARS]; int size[NLINES]; char buf[NLINES NCHARS + 3]; } LINE;

/ ... /

static char finishline (LINE lp) { int i; char p;

p = lp->buf; p++ = '\a'; p++ = '\r'; p++ = '\n'; for (i = 0; i < lp->ind; i++) { char q; int j;

for (q = lp->line[i]; q; q++) p++ = q; for (j = lp->size[i]; j < lp->maxsize + 2; j++) p++ = ' '; p++ = '\r'; p++ = '\n'; } p = 0; return lp->buf; }

In the above section of code, lp->size[2], lp->size[3], and lp->maxsize can be made large values by a remote user, such that data is written past lp->buf, if their domain name exceeds ~200 bytes. Here lp->size[2] and lp->size[3] refer to the following lines and lp->size[2] is equal to lp->maxsize:

talk: connection requested by yourname@longname talk: respond with: talk yourname@longname

The original reporter said they were able to write approximately 138 bytes past the end of lp->buf. I did not test that myself, but since I could reproduce the issue with a ~200-byte hostname added to my /etc/hosts file, and domain names can be ~50 characters longer, that number sounds about correct to me.

Patch

The fix for this issue was pushed to the GNU Inetutils repository today. Here is the associated commit:

https://codeberg.org/inetutils/inetutils/commit/81987d968ab831c08bd7e42a46f4a4823729cf1e

The patch applies cleanly to the latest release, inetutils-2.8. It can be applied like so:

$ curl --silent https://codeberg.org/inetutils/inetutils/commit/81987d968ab831c08bd7e42a46f4a4823729cf1e.patch | sed '1,41d' > talkd-fix.patch $ for a in sha2 sha3; do cksum -a $a -l 256 talkd-fix.patch; done SHA256 (talkd-fix.patch) = 5289d195b427020738953828c5851bf988be533843e015b50d95a49a7c34062c SHA3-256 (talkd-fix.patch) = 5ff65824225cb585e5ab6501f4a0550ade1ee8f75851b399b5c899ff41d5cf62 $ patch -p1 < talkd-fix.patch patching file talkd/announce.c patching file talkd/intalkd.h patching file talkd/talkd.c

Credits

Many thanks to Tristan Madani <tristan () talencesecurity com> for the detailed report and for reviewing the patch.

Timeline

2026-07-02: Report sent to inetutils-security () gnu org 2026-07-02: I (Collin Funk) acknowledged the report and asked a few questions regarding the issue. 2026-07-04: Tristan answered those questions. 2026-07-06: I reproduced the issue updated Tristan with a planned timeline for the fix and CVE assignment. 2026-07-08: Tristan agreed to the timeline and offered to review the patch. 2026-07-11: I wrote the patch and sent it to Tristan. 2026-07-15: Tristan confirmed the patch worked as expected. 2026-07-16: Private mail to distros mailing list along with the patch. 2026-07-24: I wrote this report and sent it to oss-security.

Note that I also requested a CVE when emailing distros, but haven't heard back. I'll probably reach out privately to a CNA in a bit, and will update here once one is assigned.

Collin

[1] https://codeberg.org/inetutils/inetutils/commit/9974e41e9fd957b0271d4dc0af773a9f998f1eb2 [2] https://sources.debian.org/src/util-linux/2.41-5/debian/NEWS#L1-L9 [3] https://www.gnu.org/software/inetutils/manual/inetutils.html#Access-control-in-talkd [4] https://codeberg.org/inetutils/inetutils/src/commit/c4b87ff6cd5ebcd5e0b1de748eba348da38a0a15/talkd/process.c#L69-L84 [5] https://codeberg.org/inetutils/inetutils/src/commit/c4b87ff6cd5ebcd5e0b1de748eba348da38a0a15/talkd/process.c#L93-L96 [6] https://codeberg.org/inetutils/inetutils/src/commit/c4b87ff6cd5ebcd5e0b1de748eba348da38a0a15/talkd/announce.c#L140-L145 [7] https://codeberg.org/inetutils/inetutils/src/commit/c4b87ff6cd5ebcd5e0b1de748eba348da38a0a15/talkd/process.c#L162-L163 [8] https://www.gnu.org/software/inetutils/manual/inetutils.html#talk003a-a-communication-program [9] https://codeberg.org/inetutils/inetutils/src/commit/c4b87ff6cd5ebcd5e0b1de748eba348da38a0a15/talkd/announce.c#L47-L60 [10] https://codeberg.org/inetutils/inetutils/src/commit/c4b87ff6cd5ebcd5e0b1de748eba348da38a0a15/talkd/announce.c#L25-L39 [11] https://codeberg.org/inetutils/inetutils/src/commit/c4b87ff6cd5ebcd5e0b1de748eba348da38a0a15/talkd/announce.c#L62-L86

The CVE id CVE-2026-53910 was assigned to GNU diffutils. In my personal opinion, the CVE description is an absolute joke [1]:

An attacker who can control the output of the diff program used by diff3 (e.g. via --diff-program pointing to a malicious script) can trigger out-of-bounds writes, resulting in a crash and potentially remote code execution depending on the environment.

An LLM generated report was sent to myself and a few others on 2026-04-20, showing that you could write a script and pass it to 'diff3' as the option to '--diff-program' to overflow an integer and then write 4 bytes of data into a bogus address, crashing it with ASAN enabled.

This is a bug of course, and we are thankful the report. However, Paul Eggert and I responded to the private report saying the obvious, that if someone has access your system to execute arbitrary programs, surely there are more productive things to do than feeding 'diff3' garbage.

More annoying is the fear-mongering that every single out-of-bounds memory access is "potentially remote code execution" by definition, without any attempt to provide evidence of such.

My annoyance from CVE reports like this is due to the fact that they waste everyones time. Customers ask vendors for CVEs in their images to be fixed, as they should, to avoid potential vulnerabilities. Distribution maintainers rightfully ask for new releases to fix vulnerabilities, likewise, as they should, as they did in this case [2]. This becomes a nuisance when every little bug, with dubious security implications is reported as a security issue.

As an example, at my day job I constantly see GNU coreutils CVE-2025-5278 in CVE scans [3]. Here is the NEWS entry associated with the bug fix:

'sort' with key character offsets of SIZEMAX, could induce a read of 1 byte before an allocated heap buffer. For example: 'sort +0.18446744073709551615R input' on 64 bit systems. [bug introduced in coreutils-7.2]

Obviously, this is not really a security concern. It was brought up on oss-security and Simon McVittie brought up some similar criticisms to the ones I mention [4]. Likewise the report to the Debian package says something similar [5]:

Not sure why this got a CVE assigned, it seems like a regular crash without genuine security implications.

I'm beginning to consider if becoming a CNA would save everyones time, to avoid treating every bug as a security issue if the reported could dream up a hypothetical scenario where it is one. I mentioned this on coreutils () gnu org after seeing CVE-2026-56391 and CVE-2026-56392 assigned, which feel more like bugs than security issues [6]. But I figured maybe people oss-security would have some interesting input as well.

Collin

[1] https://nvd.nist.gov/vuln/detail/CVE-2026-53910 [2] https://lists.gnu.org/archive/html/bug-diffutils/2026-07/msg00005.html [3] https://nvd.nist.gov/vuln/detail/CVE-2025-5278 [4] https://www.openwall.com/lists/oss-security/2025/05/29/1 [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1106733 [6] https://lists.gnu.org/archive/html/coreutils/2026-07/msg00048.html

GNU coreutils unexpand is vulnerable to a heap-based buffer overflow due to an integer overflow during buffer allocation when processing large tab stop (-t) values. The multiplication used to calculate the allocation size can wrap around, resulting in an undersized buffer. When processing crafted input, subsequent writes exceed the allocated memory, leading to an out‑of‑bounds heap write.

When running GNU coreutils unexpand with attacker-provided large tab stop (-t) arguments, this behavior leads to a crash and potentially achieve a heap write primitive depending on memory layout.

This issue has been fixed in the commit b60a159fdc5bfcf9988d3a4cb6f53abe8ad5d35d

GNU coreutils uniq is vulnerable to an out‑of‑bounds read due to incorrect handling of multibyte input when the -w (--check-chars) option is used. The findfield() function miscalculates the byte length of characters by repeatedly processing a fixed pointer instead of advancing through the input, resulting in an inflated length value. This incorrect length is later used in a memcmp operation, causing reads beyond the allocated buffer when processing crafted multibyte input.