GNU LibreDWG through 0.14.8612 contains a global out-of-bounds read vulnerability in the AcDs decoder acdsprivate() that allows attackers to read beyond a static table via an unchecked schema property type index. Attackers can supply a crafted R2004 or R2010+ DWG file with a large 'schdat' property type value to crash dwgread, dwg2dxf, or any application using LibreDWG.

Hi,

On Wed, Oct 14, 2026 at 10:17:08AM +0100, Sam James wrote: Sean Whitton <spwhitton () spwhitton name> writes: Wonyoung Jung of 78ResearchLab, using their PatchHawk tool, discovered that the fix for CVE-2026-79992 was incomplete. The tramp-user-regexp failed to check for some additional problematic characters in user names, meaning that exploitation was still possible.

The attached patch by TRAMP maintainer Michael Albinus addresses the problem. It will be included in Emacs 31.2 though that won't be released soon. Red Hat, would you be willing to provide another CVE for this? Thank you. FWIW, this is already https://www.cve.org/CVERecord?id=CVE-2026-108976 .

Regards, Salvatore

Sean Whitton <spwhitton () spwhitton name> writes: Wonyoung Jung of 78ResearchLab, using their PatchHawk tool, discovered that the fix for CVE-2026-79992 was incomplete. The tramp-user-regexp failed to check for some additional problematic characters in user names, meaning that exploitation was still possible.

The attached patch by TRAMP maintainer Michael Albinus addresses the problem. It will be included in Emacs 31.2 though that won't be released soon. Red Hat, would you be willing to provide another CVE for this? Thank you.

A flaw was found in m17n-lib. The decodecodingiso2022() function in src/coding.c reads uninitialized stack memory when decoding crafted input using the ISO-2022 Compound Text extension. An ESC % G escape sequence activates UTF-8 shifting, after which an invalid UTF-8 lead byte of 0xFE or 0xFF causes CHARBYTESBYHEAD() to return zero. The decoder skips the continuation-byte initialization loop, leaving buf[1] through buf[5] of its local int buf[6] array uninitialized, but still passes the buffer to UTF8CHARSET() and STRINGCHARUTF8(). The resulting character value can incorporate data from uninitialized stack contents and be stored in the decoded text. An attacker able to supply input to an application using this decoding path may cause nondeterministic output and potentially limited information disclosure if the application exposes the decoded values. Reliable disclosure of sensitive process memory has not been demonstrated.

GNU Aspell 0.60.8.2 (first vulnerable version is not known) contains a heap-based buffer overflow write (CWE-122) in its read-only dictionary loader. String::reserve() in common/string.hpp computes its capacity check with a signed int ((int)s + 1), so a requested size of 0x7FFFFFFF wraps negative and the backing buffer is never grown. ReadOnlyDict::load() in modules/speller/default/readonlyws.cpp passes the unvalidated 32-bit size fields from a .rws dictionary header into this path, so a crafted .rws file with a valid endian marker (12345678) and an oversized length field (e.g. langnamesize = 0x7FFFFFFF) causes attacker-controlled data to be written out of bounds past an undersized heap allocation. An attacker who induces a victim to load a malicious dictionary — for example via aspell dump master <file> — can corrupt heap memory, resulting in denial of service and potentially code execution. Fixed in b830b6e and will be fixed in release 0.60.8.3.

GNU Emacs before 31.2 (and TRAMP through 2.8.2) allows OS command injection via a filename because tramp-user-regexp has an incomplete list of disallowed inputs. NOTE: this issue exists because of an incomplete fix for CVE-2026-79992.

Wonyoung Jung of 78ResearchLab, using their PatchHawk tool, discovered that the fix for CVE-2026-79992 was incomplete. The tramp-user-regexp failed to check for some additional problematic characters in user names, meaning that exploitation was still possible.

The attached patch by TRAMP maintainer Michael Albinus addresses the problem. It will be included in Emacs 31.2 though that won't be released soon.

-- >8 -- From: Michael Albinus <michael.albinus () gmx de>

diff --git a/lisp/net/tramp-archive.el b/lisp/net/tramp-archive.el index 2c7a65b375f..59442bb1c2b 100644 --- a/lisp/net/tramp-archive.el +++ b/lisp/net/tramp-archive.el @@ -741,6 +741,20 @@ tramp-archive-handle-not-implemented v 'remote-file-error "Operation %s' not implemented for file archives" operation)))

+;;; Default connection-local variables for Tramp. + +(defconst tramp-archive-connection-local-default-variables + '((tramp-allow-double-percent . t)) + "Default connection-local variables for file archives.") + +(connection-local-set-profile-variables + 'tramp-archive-connection-local-default-profile + tramp-archive-connection-local-default-variables) + +(connection-local-set-profiles + (:application tramp :protocol ,tramp-archive-method) + 'tramp-archive-connection-local-default-profile) + (add-hook 'tramp-unload-hook (lambda () (unload-feature 'tramp-archive 'force))) diff --git a/lisp/net/tramp.el b/lisp/net/tramp.el index 1c1d05d91e0..eec297ef5cf 100644 --- a/lisp/net/tramp.el +++ b/lisp/net/tramp.el @@ -1071,7 +1071,7 @@ tramp-postfix-method-regexp Derived from tramp-postfix-method-format'.")

(defconst tramp-user-regexp - (rx (| (+ (not (any "/\\^$?:;|[]{}()<>'\"" blank))) + (rx (| (+ (not (any "/\\^$!#&?:;,|[]{}()<>'\"" blank control))) ;; Environment variable. (: "$" (+ (any "" alnum))))) "Regexp matching user names.") @@ -1837,6 +1837,11 @@ tramp-find-host result (propertize result 'tramp-default t))))

+(defvar tramp-allow-double-percent (not (eq system-type 'windows-nt)) + "Whether a pattern \"%NAME%\" can be used in user or host names. +It is not recommended to change this variable globally. Instead, it +should be set connection-local.") + ;;;###tramp-autoload (defun tramp-dissect-file-name (name &optional nodefault) "Return a tramp-file-name' structure of NAME, a remote file name. @@ -1903,7 +1908,37 @@ tramp-dissect-file-name ;; Only some methods from tramp-sh.el do support multi-hops. (unless (or (null hop) nodefault non-essential (tramp-multi-hop-p v)) (tramp-user-error - v "Method %s' is not supported for multi-hops" method))))))) + v "Method %s' is not supported for multi-hops" method)) + (let (connection-local-variables-alist) + (hack-connection-local-variables + (tramp-get-connection-local-criteria v)) + (let ((allow-double-percent + (alist-get + 'tramp-allow-double-percent + connection-local-variables-alist + tramp-allow-double-percent))) + ;; User name could be invalid after expansion of + ;; environment variables, or contain a literal + ;; environment variable. + (unless (tramp-string-empty-or-nil-p user) + (when (or (not (string-match-p tramp-user-regexp user)) + (string-match-p + (rx "$") (tramp-file-name-user-domain v)) + (and (not allow-double-percent) + (string-match-p + (rx "%" ( nonl) "%") + (tramp-file-name-user-domain v)))) + (tramp-user-error + v "Not a valid user name: \"%s\"" + (tramp-file-name-user-domain v)))) + ;; Host name could contain a literal environment variable. + (unless (tramp-string-empty-or-nil-p host) + (when (or (not (string-match-p tramp-host-regexp host)) + (string-match-p (rx "$") host) + (and (not allow-double-percent) + (string-match-p (rx "%" ( nonl) "%") host))) + (tramp-user-error + v "Not a valid host name: \"%s\"" host))))))))))

;; We cannot use the declare' form for tramp-suppress-trace' in ;; autoloaded functions, because the tramp-loaddefs.el generation

-- Sean Whitton

https://cert.pl/en/posts/2026/10/CVE-2026-75818/ says: CERT Polska has received a report about vulnerabilities in GNU Aspell software and participated in coordination of their disclosure.

The vulnerability CVE-2026-75818: GNU Aspell prezip-bin contains a heap-based buffer overflow vulnerability in the decompressor in prog/prezip.c. The decompressor does not properly check buffer space, so a crafted compressed file can cause out-of-bounds read and write operations on the heap. An attacker who convinces a user to process a malicious compressed file with prezip-bin can trigger memory corruption, leading to a processs crash.

This issue was fixed in commit 15b188437f9e0192d4ac4472ad66a4e2f62a782f which will be released in version 0.60.8.3.

The vulnerability CVE-2026-75819: GNU Aspell contains an out-of-bounds read vulnerability in ReadOnlyDict::load() in readonlyws.cpp. When loading a binary .rws dictionary file, it uses offset fields from the file header as byte indices into a heap buffer without validating their bounds. An attacker can trigger this by convincing a user to run aspell with a crafted dictionary file supplied through --master, --dict-dir, or configuration options, leading to heap memory disclosure or a denial of service via application crash.

This issue was fixed in commit 941953b25031bc9104e83f58e138a664b8dedc3f which will be released in version 0.60.8.3.

The vulnerability CVE-2026-75820: GNU Aspell contains an integer truncation vulnerability in the WritableDict::add() function in modules/speller/default/writable.cpp. When loading a personal wordlist, the word length is stored as a single byte, causing truncation for words whose length is a multiple of 256. This leads to heap corruption. An attacker can exploit this by convincing a user to run aspell with a crafted personal wordlist containing such a word, resulting in denial of service.

This issue was fixed in commit 782ce94e4dc71eaec4ee1bd945eb3b9c47c5387d which will be released in version 0.60.8.3.

Credits ------- We thank Michał Majchrowicz and Marcin Wyczechowski from AFINE Team for the responsible vulnerability report.

Improper certificate validation in gnutls v3.8.13 causes the application to accept certificates containing invalid extensions.

A flaw was found in m17n-lib. An attacker could provide specially crafted or truncated UTF-8 input to trigger an unhandled null pointer dereference during text processing. This issue causes the application to crash unexpectedly, resulting in a Denial of Service (DoS).

A flaw was found in m17n-lib. A partial failure during m17ninit() can leave the internal minputdriver pointer NULL. A subsequent call to minputopenim() can dereference this NULL pointer instead of returning an initialization error, resulting in a crash. No reproducer was supplied for this claim, and attempts to force the specific precondition (an early module-init failure inside m17ninit(), e.g. via a bogus M17NDIR) did not trigger it directly -- the library tolerates a missing or invalid database path gracefully in the tested configuration. Source review of src/m17n.c confirms the claimed code path is real: m17ninit() calls a chain of module initializers (mcharsetinit, mcodinginit, mcharsetloadfromdatabase, mcodingloadfromdatabase, mlanginit, mlocaleinit) and jumps to an err: label on the first failure, which skips the subsequent minputinit() call entirely. minputinit() is the only place the global minputdriver pointer is assigned; it is NULL otherwise. src/input.c:4786 then does driver = minputdriver; and src/input.c:4799 dereferences it unconditionally via im->driver = driver; with no NULL check. The crash is real but requires one of the six earlier module initializers to fail first (e.g. under memory pressure or a corrupted system m17n database), a narrower precondition than the other three issues reported alongside this one. No live reproduction was achieved; this assessment is based on code review alone.

A flaw was found in m17n-lib. An invalid UTF-8 sequence containing a lead byte in the 0xFE-0xFF range can cause countutf8chars() (src/mtext.c) to make no parsing progress, resulting in an infinite loop and sustained CPU consumption when processing crafted M-text input. Independently reproduced: a crafted .mim database entry containing byte 0xFF causes the plain build to spin at ~100% CPU until killed (confirmed via time: ~4.9s of CPU time consumed in a 5s window, process required external termination). Root cause confirmed in src/mtext.c: CHARUNITSBYHEADUTF8(0xFF) returns 0, so the scanning pointer in countutf8chars() never advances. Upstream maintainer Kenichi Handa reviewed the report and confirmed the affected byte range is 0xFE-0xFF rather than the broader 0xFC-0xFF range originally suggested by the reporter.

GNU Aspell contains an integer truncation vulnerability in the WritableDict::add() function in modules/speller/default/writable.cpp. When loading a personal wordlist, the word length is stored as a single byte, causing truncation for words whose length is a multiple of 256. This leads to heap corruption. An attacker can exploit this by convincing a user to run aspell with a crafted personal wordlist containing such a word, resulting in denial of service.

This issue was fixed in commit 782ce94e4dc71eaec4ee1bd945eb3b9c47c5387d which will be released in version 0.60.8.3.

GNU Aspell contains an out-of-bounds read vulnerability in ReadOnlyDict::load() in readonlyws.cpp. When loading a binary .rws dictionary file, it uses offset fields from the file header as byte indices into a heap buffer without validating their bounds. An attacker can trigger this by convincing a user to run aspell with a crafted dictionary file supplied through --master, --dict-dir, or configuration options, leading to heap memory disclosure or a denial of service via application crash.

This issue was fixed in commit 941953b25031bc9104e83f58e138a664b8dedc3f which will be released in version 0.60.8.3.

GNU Aspell prezip-bin contains a heap-based buffer overflow vulnerability in the decompressor in prog/prezip.c. The decompressor does not properly check buffer space, so a crafted compressed file can cause out-of-bounds read and write operations on the heap. An attacker who convinces a user to process a malicious compressed file with prezip-bin can trigger memory corruption, leading to a processs crash.

This issue was fixed in commit 15b188437f9e0192d4ac4472ad66a4e2f62a782f which will be released in version 0.60.8.3.

-------- Forwarded Message -------- Subject: groff 1.24.2 released Date: Tue, 29 Sep 2026 02:54:35 -0500 From: G. Branden Robinson <g.branden.robinson () gmail com> To: info-gnu () gnu org, info-groff () gnu org CC: groff () gnu org, linux-man () vger kernel org

We are anxious to announce the availability of groff 1.24.2. This release resolves recently discovered security vulnerabilities affecting all groff releases dating back to 2012, and even farther.

Obtain it from the GNU mirror network,

https://ftpmirror.gnu.org/groff/groff-1.24.2.tar.gz

or, if the network is for some reason inoperative, directly from GNU.

https://ftp.gnu.org/gnu/groff/groff-1.24.2.tar.gz

Ensure the integrity of your download by checking this source code archive's cryptographic signature; see "Obtaining groff" below.

What is groff? ==============

groff (GNU roff) is a typesetting system that reads plain text input that includes formatting commands to produce output in PostScript, PDF, HTML, or DVI formats or for display to a terminal. Formatting commands can be low-level typesetting primitives, macros from a supplied package, or user-defined macros. All three approaches can be combined.

A reimplementation and extension of troff and other programs from AT&T Unix, groff is widely available on POSIX and other systems owing to its long association with Unix manuals, including man pages. It and its predecessor have produced several best-selling software engineering texts. groff can create typographically sophisticated documents while consuming minimal system resources.

https://www.gnu.org/software/groff/

Details -------

Since groff 1.24.1 was released on 14 March 2026, 2 people have authored a total of 6 commits on the "1.24.x" stable branch.

5 G. Branden Robinson 1 Deri James

This release resolves the following issues in the GNU Savannah ticket tracker.

bug #68689: [PATCH] [mm] mmroff vulnerable to command injection (CWE-78) bug #68688: [PATCH] [grohtml] pre-grohtml vulnerable to command injection (CWE-78) bug #68687: [PATCH] [pdfmom] vulnerable to command injection (CWE-78) bug #68152: [gxditview] SEGVs when invoked with no arguments

One way of capturing the amount of revision is as follows.

$ COLUMNS=72 git diff --stat 1.24.1 1.24.2 ChangeLog | 52 +++++++++++++++++++++++++++++++++ NEWS | 21 +++++++++++++ arch/mingw/grap2graph.cmd | 2 +- contrib/mm/ChangeLog | 15 ++++++++++ contrib/mm/mmroff.pl | 2 +- doc/webpage.ms | 2 +- src/devices/gropdf/pdfmom.pl | 29 ++++++++++++------ src/devices/xditview/xditview.c | 24 ++++++++------- src/preproc/html/pre-html.cpp | 11 +++++++ src/roff/troff/input.cpp | 14 +++++++++ 10 files changed, 149 insertions(+), 23 deletions(-)

Obtaining groff ===============

Here are the compressed sources and a GPG detached signature[]. https://ftp.gnu.org/gnu/groff/groff-1.24.2.tar.gz https://ftp.gnu.org/gnu/groff/groff-1.24.2.tar.gz.sig

Use a mirror for higher download bandwidth. https://ftpmirror.gnu.org/groff/groff-1.24.2.tar.gz https://ftpmirror.gnu.org/groff/groff-1.24.2.tar.gz.sig

Here are the SHA-1 and SHA-256 checksums.

8f43c4d049207689b85af8a211742d87356e64e6 groff-1.24.2.tar.gz +cHv1b6743/G4QY9t0c86N8ePgvk/w9DzgT85X6cXdk= groff-1.24.2.tar.gz

The SHA-256 checksum is encoded in Base64 instead of the hexadecimal form that most checksum tools default to. The mechanism follows.

sha256sum < groff-1.24.2.tar.gz | cut -f1 -d\ | xxd -r -p | base64

(Because "base64" reads from a pipe, it doesn't know the file name, and so the file name will not appear in the output.)

[] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding archive. Then, verify the archive.

gpg --verify groff-1.24.2.tar.gz{.sig,}

If that command fails because you don't have the required public key, you can import it.

wget -O 108747.asc \ 'https://savannah.gnu.org/people/viewgpg.php?userid=108747&apos; gpg --import 108747.asc

Re-run the 'gpg --verify' command above again subsequently.

Caveats =======

o GNU tools, or otherwise POSIX-conforming ones, are generally required to build on Solaris 10 or 11. See the "PROBLEMS" file in the distribution archive.

o Solaris 10 has known problems with automated tests; see the "PROBLEMS" file in the distribution archive.

News ====

This release corrects command injection security vulnerabilities (CWE-78) in the mmroff, pdfmom, and pre-grohtml programs. The last of these is a preprocessor that is run when groff or troff is run with the -T html or -T xhtml options. The vulnerabilities are variously 14-26 years old. Malicious input can escape groff's default "safer" mode, running commands embedded in that input at the user's privilege level. The groff development team recommends this release to any users who employ the named tools or GNU troff output formats with untrusted inputs.

Man page rendering is not vulnerable unless rendering (X)HTML.

This release also resolves a command-line argument processing defect in the gxditview program. It is not known to have any security impact.

There are no new features.

Acknowledgements ================

We'd like to thank the following people for helping ensure the quality of this release.

Deri James Ingo Schwarze Pavol Sloboda

The following security advisories have been published:

GLIBC-SA-2026-0024: ===================

One-byte overread in strncasecmp on Power8

The strncasecmp function in the GNU C Library 2.24 and later optimized for the Power8 architecture may read one byte beyond the input size limit, which may crash a program when that byte is not readable.

This condition may happen when the input strings to the strncasecmp function are attacker controlled in an application and they match all the way up to the edge of their page and the neighbouring page is either not mapped or is not readable.

CVE Id: CVE-2026-97399 Public-Date: 2026-09-28 Vulnerable-Commit: c8376f3e07602aaef9cb843bb73cb5f2b860634a (2.23.90-474) CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L - 3.7 Reported-by: AISLE in partnership with Red Hat

Notes: ======

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

One-byte overread in strncasecmp on Power8

On Fri, 25 Sep 2026 at 22:26:57 +0000, Haitam Lazaar wrote: GNU libextractor before 1.16 uses getenv("LIBEXTRACTORPREFIX") in src/main/extractorplugpath.c (getinstallationpaths()) to determine plugin search paths without checking whether the calling process is running with elevated privileges (setuid/setgid).

smcv

On 2026-09-14, Brian Mak privately reported a security issue with a function defined in libinetutils, a part of GNU Inetutils. The function is used by rlogin, rlogind, and telnetd. The possible exploits using the bug aren't entirely clear. Brian noticed the bug from 'telnetd' crashing, which could lead to a denial of service. However, from our discussions, we were also concerned about the possibility of code execution on platforms that use the SARESTORER bit of saflags and the sarestorer member of struct sigaction.

The issue and patch were sent to the linux-distros list privately by myself on 2026-09-18. If you still require the patch it can be applied cleanly to an inetutils-2.8 tarball like so:

$ tar -xf inetutils-2.8.tar.gz $ cd inetutils-2.8 $ curl --silent --location --remote-name https://codeberg.org/inetutils/inetutils/commit/f756321da9b964fc27fc43652b73913117883047.patch $ patch -p1 < f756321da9b964fc27fc43652b73913117883047.patch

And without further ado, here are some details about the issue, in hopes that someone can see if anything interesting is possible, or not, now that a patch is available:

The problematic function is listed in full below [1]:

/ This is exactly like the traditional signal function, but turns on the SARESTART bit where possible. / sighandlert setsig (int sig, sighandlert handler) { #ifdef HAVESIGACTION struct sigaction sa, osa; sigemptyset (&sa.samask); sigemptyset (&osa.samask); # ifdef SARESTART sa.saflags |= SARESTART; # endif sa.sahandler = handler; if (sigaction (sig, &sa, &osa) < 0) return SIGERR; return osa.sahandler; #else / !HAVESIGACTION / # ifdef HAVESIGVEC struct sigvec sv, osv; sigemptyset (&sv.svmask); sigemptyset (&osv.svmask); sv.svhandler = handler; if (sigvec (sig, &sv, &osv) < 0) return SIGERR; return osv.svhandler; # else/ !HAVESIGVEC / return signal (sig, handler); # endif/ HAVESIGVEC / #endif / HAVESIGACTION / }

We can see that undef "#ifdef SARESTART", sa.saflags has its SARESTART bit set without being initialized previously. The concern Brain raised is that, depending on the contents of the stack, sa.saflags may also have its SARESTORER bit set. In addition, the sa.sarestorer field would be uninitialized, meaning it would be set to whatever is on the stack. This field is a function pointer that is used as a signal trampoline used on some architectures, meaning that it is used to return from the signal handler back to the code that was executing at the time the signal was delivered.

I am not very familiar with these signal details, so I asked Adhemerval Zanella Netto, a glibc maintainer, if he could take a look at the report to help us better understand the security impact. He mentioned that most new generic Linux ports are not affected: The glibc sigaction always uses an stack allocated for the syscall and the SARESTORER and the sarestorer is defined by an arch-specific macro:

sysdeps/unix/sysv/linux/libcsigaction.c:

29 #ifndef SARESTORER 30 # define SETSARESTORER(kact, act) 31 # define RESETSARESTORER(act, kact) 32 #endif

46 struct kernelsigaction kact, koact; 47 48 if (act) 49 { 50 kact.ksahandler = act->sahandler; 51 memcpy (&kact.samask, &act->samask, sizeof (sigsett)); 52 kact.saflags = (unsigned int) act->saflags; 53 SETSARESTORER (&kact, act); 54 }

On most generic new ports (RISC-V, LoongArch, metc), kernel always uses the vDSO sigreturn trampoline (sarestorer is not part of the kABI). On x8664 and i386, things seem less clear: On x8664:

extern void restorert (void) asm ("restorert") attributehidden;

#define SETSARESTORER(kact, act) \ (kact)->saflags |= SARESTORER; \ (kact)->sarestorer = &restorert

So for a glibc-based binary, it is not clear to me how a corrupted input can change the sarestorer. On some ABIs you might result in a different sarestorer (like ARM/i386, that will use different ones depending whether SASIGINFO is used):

sysdeps/unix/sysv/linux/i386/libcsigaction.c:

24 extern void restorert (void) asm ("restorert") attributehidden; 25 extern void restore (void) asm ("restore") attributehidden; 26 27 #define SETSARESTORER(kact, act) \ 28 ({ \ 29 if (GLRO(dlsysinfodso) == NULL) \ 30 { \ 31 (kact)->saflags |= SARESTORER; \ 32 (kact)->sarestorer = (((act)->saflags & SASIGINFO) \ 33 ? &restorert : &restore); \ 34 } \ 35 else \ 36 (kact)->sarestorer = NULL; \ 37 }) 38 39 #define RESETSARESTORER(act, kact) \ 40 (act)->sarestorer = (kact)->sarestorer

But even in this case, the possible breakages are:

Legacy sigcontext-by-value handlers where some old code declares 'void h(int sig, struct sigcontext sc)' and reads registers from the stack. With an rt frame the handler reads garbage. If it modifies sc to change the resumed context, the change is lost, because rtsigreturn restores from ucmcontext. This does not seem the case of inetutils [2], since it does not use the sigcontext.

Restorer and frame out of sync where this happens if the corruption lands after glibc chose the restorer, or if someone calls rtsigaction directly with a hand-picked sarestorer. I also don't this is the case.

Stack usage where the rt frame is noticeably larger because it adds siginfot (128 bytes) and a ucontextt. On a tight sigaltstack, or near a stack guard, frame setup can fail. I haven't dig into inetutils source code to check if it were the case. Brian followed up and mentioned that he noticed this issue on 32-bit ARM, which can have its sarestorer set if the user sets the SARESTORER flag in saflags, as seen in the sysdeps/unix/sysv/linux/arm/libcsigaction.c file in glibc:

#define SETSARESTORER(kact, act) \ ({ \ if ((kact)->saflags & SARESTORER) \ (kact)->sarestorer = (act)->sarestorer; \ else \ { \ (kact)->sarestorer = ((kact)->saflags & SASIGINFO) \ ? defaultrtsarestorer \ : defaultsarestorer; \ (kact)->saflags |= SARESTORER; \ } \ })

He also mentioned that it seemed to be the case for arm64, as can be seen in the sysdeps/unix/sysv/linux/aarch64/libcsigaction.c file in glibc:

#define SETSARESTORER(kact, act) \ ({ \ if ((kact)->saflags & SARESTORER) \ (kact)->sarestorer = (act)->sarestorer; \ })

Adhemerval then double-checked and confirmed that powerpc, s390x, and sh also set sarestorer unconditionally. That is, the sysdeps/unix/sysv/linux/sh/kernelsigaction.h, sysdeps/unix/sysv/linux/s390/kernelsigaction.h, and sysv/linux/powerpc/kernelsigaction.h files in glibc all contain something like this:

#define SETSARESTORER(kact, act) \ (kact)->sarestorer = (act)->sarestorer

Regarding the actual security impact of this bug, it is a bit of an open question at this point. Brian said he experienced the following, which I have no reason to not disbelieve: In our case, I was able to reproduce this consistently with our custom setsockopt() implementation by exiting or using CTRL + C in the telnet session, which triggered SIGCHLD. He also mentioned that this could cause a denial of service, similar to CVE-2022-39028 [2]: telnetd in GNU Inetutils through 2.3, MIT krb5-appl through 1.0.3, and derivative works has a NULL pointer dereference via 0xff 0xf7 or 0xff 0xf8. In a typical installation, the telnetd application would crash but the telnet service would remain available through inetd. However, if the telnetd application has many crashes within a short time interval, the telnet service would become unavailable after inetd logs a "telnet/tcp server failing (looping), service terminated" error. NOTE: MIT krb5-appl is not supported upstream but is shipped by a few Linux distributions. The affected code was removed from the supported MIT Kerberos 5 (aka krb5) product many years ago, at version 1.8. I agree with his assessment. However, I want to be clear that I am not confident that nothing worse than that is possible. I don't have access to a machine (or, more likely, the knowledge) to test this, but my concern is whether it is possible that a valid address gets placed on the stack such that sa.sarestorer is set to it and later used.

This bug was introduced in GNU Inetutils 1.9, released 2011-12-31. I also have linked the commit that introduced this [3].

I would like to thank Brian Mak <brian.mak () hpe com> for reporting this issue privately, with a patch, to inetutils-security () gnu org on 2026-09-14, along with his follow-up discussion on the private list. Furthermore, I would like to thank Adhemerval Zanella Netto <adhemerval.zanella () linaro org> for his valuable input and review.

I reported it to linux-distros and Red Hat privately on 2026-09-18. Red Hat kindly assigned CVE-2026-95510 on 2026-09-22. Thanks to them as well.

Collin

[1] https://codeberg.org/inetutils/inetutils/src/commit/40f19d84c3dead93e6fef7fc1150fde5210ebdab/libinetutils/setsig.c#L27-L56 [2] https://nvd.nist.gov/vuln/detail/cve-2022-39028 [3] https://codeberg.org/inetutils/inetutils/commit/9476515fd31e416739d850c1948e9222a53deea9

Hello oss-security,

An untrusted search path vulnerability leading to Local Privilege Escalation (LPE) was identified in GNU libextractor for versions prior to 1.16. The vulnerability has been assigned CVE-2026-100310.

Description: GNU libextractor before 1.16 uses getenv("LIBEXTRACTORPREFIX") in src/main/extractorplugpath.c (getinstallationpaths()) to determine plugin search paths without checking whether the calling process is running with elevated privileges (setuid/setgid).

Because this environment variable is not an LD variable, the dynamic linker does not strip it from the environment of setuid binaries. A local unprivileged attacker can set LIBEXTRACTORPREFIX to a directory containing a malicious shared object, which is then loaded and executed with elevated privileges (e.g., euid=0) when any setuid application linked against libextractor runs. An attacker can call setuid(0) from within the shared library's constructor to achieve full root privilege escalation.

Affected Versions: libextractor >= 0, < 1.16

Fix: The issue is patched in GNU libextractor version 1.16.

References: CVE Record: https://www.cve.org/CVERecord?id=CVE-2026-100310 VulnCheck Advisory: https://www.vulncheck.com/advisories/gnu-libextractor-before-1.16-privilege-escalation-via-libextractor-prefix PoC & Technical Details: https://github.com/Haitam-lazaar/libextractor-privesc Upstream Patch: https://git.gnunet.org/gnunet/libextractor/commit/6edfa653c048800e24a17f7e8cc2bb42659b8d01.html GNU libextractor: https://www.gnu.org/software/libextractor/

Regards, Haitam Lazaar

GNU libextractor before 1.16 loads plugins from an untrusted search path specified by the LIBEXTRACTORPREFIX environment variable without proper privilege checks. A local attacker can exploit this by setting LIBEXTRACTORPREFIX to a directory containing a malicious plugin that executes arbitrary code with elevated privileges when loaded by a setuid or setgid program.

On Thu, 20 Aug 2026 04:09:29 +0100 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 CVE-2026-96269 was assigned to this issue yesterday.

-- Tomas Hoger / Red Hat Product Security

On Tue, 22 Sep 2026 15:11:54 +0000 Bas Alberts wrote: Is GitHub going to assign a CVE here? I think GitHub assignment would be ok per this part of the GitHub CNA scope definition: "vulnerabilities affecting open source projects discovered by security researchers at GitHub or Microsoft not covered by another CNA’s scope."

If GitHub is not doing assignment, Red Hat can provide it instead. If Red Hat could provide the CVE in line with the previous finding of this report batch (CVE-2026-79992) that would be greatly appreciated. CVE-2026-96442 was assigned for this issue.

-- Tomas Hoger / Red Hat Product Security

GNU Emacs 28.1 through 31.1 allows arbitrary code execution upon opening a file, because an untrusted value of read-symbol-shorthands affects the intern and unintern functions. This affects the default configuration; no particular user settings are required to trigger it.

A local cross-user code execution vulnerability exists in GNU wget (Windows builds from eternallybored.org) due to a hardcoded configuration file path (C:\msys64) that is writable by unprivileged users, allowing for arbitrary code execution via the useaskpass directive, potentially allowing local privilege escalation.

The following security advisories have been published:

GLIBC-SA-2026-0022: =================== ATSECURE programs may load attacker-controlled code via $ORIGIN

A time-of-check to time-of-use (TOCTOU) race condition in the dynamic loader (ld.so) of the GNU C Library (glibc) versions 2.14 through 2.44 allows a local attacker to escalate privileges. When expanding $ORIGIN in DTRPATH for setuid/setgid (ATSECURE) programs, glibc validates the lexically normalized search path against the trusted directories but then opens the raw, un-normalized path. On systems where the Linux fs.protectedhardlinks sysctl is disabled, a local attacker who hard-links such a program into an attacker-controlled directory and wins a race to replace an intermediate path component with a symbolic link can direct the loader outside the trusted directory, causing it to load an attacker-controlled shared object and execute arbitrary code with the elevated privileges of the program.

Exploitation requires an installed setuid or setgid binary whose DTRPATH uses $ORIGIN followed by ".." traversal that normalizes into a trusted directory, and the ability to hard-link that binary and win the race by swapping a path component for a symbolic link. Major Linux-based OS distributions ship with fs.protectedhardlinks enabled by default and mitigate the vulnerability.

CVE-Id: CVE-2026-86805 Public-Date: 2026-07-06 Vulnerable-Commit: 47c3cd7a74e8c089d60d603afce6d9cf661178d6 (2.13-113) Fix-Commit: ed0c137b97eb940b4b64981e84ed806d3276edd9 (2.45) Reported-by: Jann Horn <jannh () google com> CVSS: CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:L - 6.3

GLIBC-SA-2026-0023: =================== ATSECURE program buffer overflow via $ORIGIN processing

A stack-based buffer overflow in the dynamic loader (ld.so) of the GNU C Library (glibc) versions 2.14 through 2.44 allows a local attacker to crash or corrupt the memory of setuid/setgid (ATSECURE) programs.

When such a program's DTRPATH or DTRUNPATH begins with $ORIGIN and is followed by NUL or '/' the loader both reads past the end of the path buffer and writes past the end of a stack-allocated internal buffer. The corrupted loader stack can lead to a loader crash (denial of service) and limited disclosure of process memory.

CVE Id: CVE-2026-95818 Public-Date: 2026-08-14 Vulnerable-Commit: 47c3cd7a74e8c089d60d603afce6d9cf661178d6 (2.13-113) Fix-Commit: ed0c137b97eb940b4b64981e84ed806d3276edd9 (2.45) Reported-by: AISLE in partnership with Red Hat CVSS: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N - 3.6

A stack-based buffer overflow in the dynamic loader (ld.so) of the GNU C Library (glibc) versions 2.14 through 2.44 allows a local attacker to crash or corrupt the memory of setuid/setgid (ATSECURE) programs.

When such a program's DTRPATH or DTRUNPATH begins with $ORIGIN and is followed by NUL or '/' the loader both reads past the end of the path buffer and writes past the end of a stack-allocated internal buffer. The corrupted loader stack can lead to a loader crash (denial of service) and limited disclosure of process memory.

A time-of-check to time-of-use (TOCTOU) race condition in the dynamic loader (ld.so) of the GNU C Library (glibc) versions 2.14 through 2.44 allows a local attacker to escalate privileges. When expanding $ORIGIN in DTRPATH for setuid/setgid (ATSECURE) programs, glibc validates the lexically normalized search path against the trusted directories but then opens the raw, un-normalized path. On systems where the Linux fs.protectedhardlinks sysctl is disabled, a local attacker who hard-links such a program into an attacker-controlled directory and wins a race to replace an intermediate path component with a symbolic link can direct the loader outside the trusted directory, causing it to load an attacker-controlled shared object and execute arbitrary code with the elevated privileges of the program.

Exploitation requires an installed setuid or setgid binary whose DTRPATH uses $ORIGIN followed by ".." traversal that normalizes into a trusted directory, and the ability to hard-link that binary and win the race by swapping a path component for a symbolic link. Major Linux-based OS distributions ship with fs.protectedhardlinks enabled by default and mitigate the vulnerability.