A flaw was found in GStreamer gst-plugins-good (avidemux). In gstavidemuxriffparsevprp(), the number of available gstriffvprpvideofielddesc entries is calculated by dividing the remaining buffer size by the attacker-controlled vprp->fields value, rather than by sizeof(gstriffvprpvideofielddesc). This can cause the parser to treat more field descriptors as available than fit in the input buffer, resulting in out-of-bounds reads. Processing a crafted AVI via playbin/decodebin can crash the application (denial of service). Fixed upstream in gst-plugins-good 1.28.6 (GStreamer-SA-2026-0072).

A flaw was found in GStreamer gst-plugins-good (avidemux). When parsing FUJIFILM metadata in an AVI strd chunk, gstavidemuxparsestrd() decrements a remaining-length counter by fixed offsets (98 and 10 bytes) without verifying sufficient data remains. For crafted strd payloads of exactly 106 or 107 bytes, the counter underflows to a very large unsigned value, causing subsequent null-terminated string scanning to read far beyond the allocated heap buffer. Date-format normalization may also write beyond the buffer end. Confirmed impacts include heap out-of-bounds read, out-of-bounds write, heap information disclosure (adjacent data appearing in parsed metadata), and application crash/denial of service. The avidemux element is auto-plugged by playbin, decodebin, and gst-discoverer, so opening or previewing a crafted AVI is sufficient to trigger the issue. Fixed upstream in gst-plugins-good 1.28.6 (GStreamer-SA-2026-0072).

A flaw was found in Samba's CTDB, the clustered database service used by Samba. Insufficient integrity validation of received CTDB protocol packets allows malformed packets containing invalid field lengths, improperly terminated strings, or inconsistent packet sizes to be processed without adequate bounds checking. A remote attacker with access to the CTDB private network may trigger a denial of service through process crashes or excessive memory consumption and, in limited cases, disclose adjacent memory contents.

A flaw was found in wildfly-core. A management user could use the resolve-expression in the HAL Interface to read possible sensitive information from the Wildfly system. This issue could allow a malicious user to access the system and obtain possible sensitive information from the system.

The expand function in fio.c in Heirloom mailx 12.5 and earlier and BSD mailx 8.1.2 and earlier allows remote attackers to execute arbitrary commands via shell metacharacters in an email address.

A flaw was found in OpenSSH. This vulnerability, a heap out-of-bounds read, occurs during the cleanup of GSSAPI (Generic Security Service Application Programming Interface) indicators when a trailing NULL termination is missing in the auth-indicators array. A remote attacker, under specific configurations involving GSSAPI authentication and a Kerberos environment, could exploit this to cause the SSH authentication path to crash or abort. This leads to a denial of service (DoS), impacting the availability of the SSH service.

A flaw was found in the interactive shell of the xmllint command-line tool, used for parsing XML files. When a user inputs an overly long command, the program does not check the input size properly, which can cause it to crash. This issue might allow attackers to run harmful code in rare configurations without modern protections.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nat: use kfreercu to release ops

Florian Westphal says:

"Historically this is not an issue, even for normal base hooks: the data path doesn't use the original nfhookops that are used to register the callbacks.

However, in v5.14 I added the ability to dump the active netfilter hooks from userspace.

This code will peek back into the nfhookops that are available at the tail of the pointer-array blob used by the datapath.

The nat hooks are special, because they are called indirectly from the central nat dispatcher hook. They are currently invisible to the nfnl hook dump subsystem though.

But once that changes the nat ops structures have to be deferred too."

Update nfnatregisterfn() to deal with partial exposition of the hooks from error path which can be also an issue for nfnetlinkhook.

A flaw was found in tar. A remote attacker could exploit this vulnerability by crafting a malicious archive, leading to hidden file injection with fully attacker-controlled content. This bypasses pre-extraction inspection mechanisms, potentially allowing an attacker to introduce malicious files onto a system without detection.

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 flaw was found in libssh automatic certificate-based public key authentication. In sshuserauthpublickeyauto() in src/auth.c, the iterator over certificate candidates was not advanced correctly when configured certificates were missing or repeatedly rejected by the server. Under specific non-default certificate configurations, this could cause the client to restart the same authentication attempts indefinitely, leading to denial of service.

A flaw was found in libssh in the server-side GSSAPI Curve25519 key exchange path in src/kex-gss.c. In sshservergsskexprocessinit(), a client-controlled SSH string is unpacked into clientpubkey and then copied with memcpy(..., CURVE25519PUBKEYSIZE) without validating sshstringlen(clientpubkey). A remote unauthenticated client can send a short public key in SSHMSGKEXGSSINIT and trigger an out-of-bounds heap read during handshake processing, disclosing small amounts of adjacent server memory.

A flaw was found in libssh server-side SFTP directory listing. In processreaddir() in src/sftpserver.c, the server allocates a fixed stack buffer as char longname[MAXLONGNAMELEN] and passes attacker-controlled directory entry names into readdirlongname(). In the pre-patch implementation, readdirlongname() appends metadata and the filename into zlongname with repeated unbounded strcat() calls. Because zlongname points at the caller-owned fixed stack buffer, sufficiently long filenames in an attacker-controlled directory can overflow that stack buffer during SSHFXPREADDIR processing, leading to crashes and possible code execution on the server.

Last updated 24 July 2024

A flaw was found in gfs2-utils. In the gfs2edit tool, the metapathtolblock() function in extended.c uses the diheight field from on-disk inode metadata as an array index into a fixed-size stack array factor[GFS2MAXMETAHEIGHT] (10 elements) without bounds validation. An attacker can craft a GFS2 filesystem image with diheight exceeding 10 (up to 65535) to write past the end of the array, corrupting adjacent stack memory including saved registers and the return address. The subsequent loop (factor[h] = factor[h+1] sbd.sdinptrs) amplifies the corruption by writing additional entries past the array boundary. This is a classic stack buffer overflow that may allow arbitrary code execution when gfs2edit processes the crafted image. The Linux kernel GFS2 driver validates diheight against sdmaxheight in gfs2dinodein(), but the userspace gfs2-utils performs no equivalent validation.

A flaw was found in gfs2-utils. The metadata walk code in metawalk.c uses alloca((height + 1) sizeof(metalist)) where height is the iheight field from the on-disk inode (uint16, max 65535, valid range 0-10). No bounds validation is performed before the alloca call. An attacker can craft a GFS2 filesystem image with a large iheight value to cause excessive stack allocation (~1MB for iheight=65535 with sizeof(osilistt)=16), leading to stack exhaustion and a denial of service (SIGSEGV). The metadata walk in metawalk.c involves recursive traversal, and each level could invoke this alloca, compounding the stack usage. The Linux kernel GFS2 driver validates iheight against sdmaxheight in gfs2dinodein() and stores it as u8, but the userspace gfs2-utils performs no equivalent validation.

A flaw was found in gfs2-utils. The eanumptrs field from on-disk extended attribute metadata is used as a loop count in savemeta.c and metawalk.c without bounds validation. The eanumptrs field is a u8 (max 255). Each iteration reads a pointer (8 bytes) plus name data. With eanumptrs=255 and a 512-byte block buffer, the loop reads up to 1384 bytes past the buffer boundary, causing a heap out-of-bounds read. This may disclose sensitive heap memory contents through tool output or error messages, and the significant over-read (2.7x the allocation) has a non-trivial probability of crossing a page boundary into unmapped memory, causing a crash.

A flaw was found in gfs2-utils. In the savemeta function in savemeta.c, the height value from on-disk inode metadata controls a loop over a fixed-size stack array (10 elements) without bounds validation. An attacker can craft a GFS2 filesystem image with a height value exceeding 10 to write past the end of the array, corrupting adjacent stack memory. This is the same vulnerability class as the diheight OOB write in gfs2edit (extended.c) but in a different code path. The stack buffer overflow may allow arbitrary code execution when savemeta processes the crafted image. The Linux kernel GFS2 driver validates iheight against sdmaxheight in gfs2dinodein(), but the userspace gfs2-utils performs no equivalent validation.

This is a vulnerability report sent to us through https://issues.redhat.com/browse/PSIRTSUPT-17960 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.

Six memory corruption vulnerabilities were found in gfs2-utils (the GFS2 filesystem utilities). All vulnerabilities are triggered by crafted GFS2 filesystem images and affect utilities that run as root. All findings were verified against upstream commit 8d07499.

The findings are:

1. Stack overflow via alloca(1<<didepth) with unbounded depth value read from superblock/inode metadata. An attacker-controlled didepth value causes an excessively large stack allocation, leading to stack exhaustion and crash or potential code execution. (CVSS 7.8, CWE-770)

2. Stack out-of-bounds write via unchecked diheight field in gfs2edit. The diheight value from inode metadata is used as an array index without bounds checking, enabling a stack buffer overflow. (CVSS 7.8, CWE-787)

3. Stack out-of-bounds write via unchecked height field in savemeta. Similar to finding 2, the height field is used without validation, causing a stack out-of-bounds write. (CVSS 7.8, CWE-787)

4. Heap out-of-bounds read via unchecked eanumptrs field. The eanumptrs value from extended attribute metadata is consumed without validation, causing a heap buffer over-read that may leak sensitive memory contents. (CVSS 5.5, CWE-125)

5. Integer overflow in resource group (rgrp) allocation size computation. An arithmetic overflow in the allocation size calculation leads to an undersized buffer allocation followed by out-of-bounds access. (CVSS 5.5, CWE-190)

6. Stack overflow via alloca(iheight) with unbounded inode height value. Similar to finding 1, an unbounded height value causes excessive stack allocation. (CVSS 5.5, CWE-770)

All vulnerable code paths reside in core filesystem metadata parsing logic within libgfs2 and utility-specific code that is unconditionally compiled into all shipped binaries. There are no build-time flags or conditional compilation options that can exclude the affected code. The most realistic attack scenario involves a crafted GFS2 image on removable or network-attached storage being processed by fsck.gfs2 (either automatically at boot or manually by an administrator) in a high-availability clustered environment.

RHEL compiler hardening (stack protector, FORTIFYSOURCE, PIE, full RELRO) provides partial mitigation for the CWE-787 stack out-of-bounds write vulnerabilities but is ineffective against alloca-based CWE-770 stack exhaustion.

No upstream fix or advisory has been published. The reporter has requested individual CVE assignment for each of the six distinct findings.

A double-free vulnerability exists in GIMP's Paint Shop Pro (PSP) file format parser. In readlayerblock() in file-psp.c, the variable name is allocated, used, and freed each loop iteration. On the error path in the 2nd iteration, fread fails before gmalloc for name, so the stale pointer from iteration 1 is freed again via gfree(name).

- Function: readlayerblock() - File: plug-ins/common/file-psp.c:1908-2321 - Fix: https://gitlab.gnome.org/GNOME/gimp/-/commit/b22e147b - Upstream issue: https://gitlab.gnome.org/GNOME/gimp/-/issues/16207 - Acknowledgment: bb1abu

In the Linux kernel, the following vulnerability has been resolved:

A vulnerability has been discovered in the way RH-SSO handles offline tokens, which can be exploited to cause a denial of service via memory exhaustion. The issue is caused by the way how the server processes offline tokens.

An attacker can exploit this vulnerability by creating just two offline tokens. Once these tokens are created, the attacker can interact with the endpoint by triggering a list of the multiple sessions of the user. In environments where there could be potentially millions of offline tokens created by all users, this action leads to an excessive consumption of server memory.

A flaw was found in the redirecturi validation logic in Keycloak. This issue may allow a bypass of otherwise explicitly allowed hosts. A successful attack may lead to an access token being stolen, making it possible for the attacker to impersonate other users.

A flaw was found in Keycloak that prevents certain schemes in redirects, but permits them if a wildcard is appended to the token. This issue could allow an attacker to submit a specially crafted request leading to cross-site scripting (XSS) or further attacks. This flaw is the result of an incomplete fix for CVE-2020-10748.

A vulnerability identified in NetIQ Advance Authentication that leaks sensitive server information. This issue affects NetIQ Advance Authentication version before 6.3.5.1

Accessibility. A logic issue was addressed with improved checks.

A flaw was found in OpenJPEG. A resource exhaustion can occur in the opjt1decodecblks function in tcd.c through a crafted image file, causing a denial of service.

A flaw was found in OpenJPEG. Maliciously constructed pictures can cause the program to enter a large loop and continuously print warning messages on the terminal.

A vulnerability has been identified in the libarchive library, specifically within the archivereadformatrarseekdata() function. This flaw involves an integer overflow that can ultimately lead to a double-free condition. Exploiting a double-free vulnerability can result in memory corruption, enabling an attacker to execute arbitrary code or cause a denial-of-service condition.