A security vulnerability was found in zlib. The flaw triggered a heap-based buffer in inflate in the inflate.c function via a large gzip header extra field. This flaw is only applicable in the call inflateGetHeader.

Summary

Out-of-bounds Write vulnerability in the bundled Brotli decoder in yjh0502 erl-brotli allows an attacker who supplies a crafted Brotli-compressed stream to brotli:decode/1 to corrupt decoder state memory, disclose memory contents, crash the Erlang VM, or potentially execute code.

erl-brotli compiles its own copy of the Google Brotli C sources under csrc into a NIF, and brotlidecoderdecompressstream in csrc/brotlinif.c hands the input to BrotliDecoderDecompressStream. In csrc/dec/decode.c, DecodeBlockTypeAndLength returns false for a block switch in a category with at most one block type, and the non-streaming callers DecodeLiteralBlockSwitch, DecodeCommandBlockSwitch and DecodeDistanceBlockSwitch discard that result, so decoding continues with inconsistent state. The decoder runs inside a NIF, so memory corruption or a crash takes down the whole VM rather than the calling process. Because the package carries its own copy of the library, the Brotli version installed on the host does not matter.

This issue affects brotli: from 0.3.0 before 0.3.4.

Impact

An attacker who can get an application to decode a Brotli stream they control, for example an HTTP client that decompresses Content-Encoding: br responses with this package, can crash the Erlang VM and potentially run code inside it.

Last updated 20 March 2025

Mbed TLS before 3.0.1 has a double free in certain out-of-memory conditions, as demonstrated by an mbedtlssslsetsession() failure.

gio/gsocks4aproxy.c in GNOME GLib before 2.82.1 has an off-by-one error and resultant buffer overflow because SOCKS4CONNMSGLEN is not sufficient for a trailing '\0' character.

As per upstream samba advisory:

All versions of Samba from 3.5.0 onwards are vulnerable to a remote code execution vulnerability, allowing a malicious client to upload a shared library to a writable share, and then cause the server to load and execute it.

External References:

https://www.samba.org/samba/security/CVE-2017-7494.html

Acknowledgements:

Name: the Samba project Upstream: steelo

A use after free can have a range of potential consequences such as the corruption of valid data, crashes or execution of arbitrary code. However, only applications that directly call the SSLfreebuffers function are affected by this issue. Applications that do not call this function are not vulnerable. Our investigations indicate that this function is rarely used by applications.

The SSLfreebuffers function is used to free the internal OpenSSL buffer used when processing an incoming record from the network. The call is only expected to succeed if the buffer is not currently in use. However, two scenarios have been identified where the buffer is freed even when still in use.

The first scenario occurs where a record header has been received from the network and processed by OpenSSL, but the full record body has not yet arrived. In this case calling SSLfreebuffers will succeed even though a record has only been partially processed and the buffer is still in use.

The second scenario occurs where a full record containing application data has been received and processed by OpenSSL but the application has only read part of this data. Again a call to SSLfreebuffers will succeed even though the buffer is still in use.

While these scenarios could occur accidentally during normal operation a malicious attacker could attempt to engineer a stituation where this occurs. We are not aware of this issue being actively exploited.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

OpenSSL 1.0.2 is also not affected by this issue.

OpenSSL 3.3, 3.2, 3.1, 3.0 and 1.1.1 are vulnerable to this issue.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.1 once it is released.

OpenSSL 3.2 users should upgrade to OpenSSL 3.2.2 once it is released.

OpenSSL 3.1 users should upgrade to OpenSSL 3.1.6 once it is released.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.14 once it is released.

OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1y once it is released (premium support customers only).

Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit e5093133c3 (for 3.3), commit c88c3de510 (for 3.2), commit 704f725b96 (for 3.1) and commit b3f0eb0a29 (for 3.0) in the OpenSSL git repository. It is available to premium support customers in commit f7a045f314 (for 1.1.1).

This issue was reported on 10th April 2024 by William Ahern (Akamai). The fix was developed by Matt Caswell and Watson Ladd (Akamai).

In MIT Kerberos 5 (aka krb5) before 1.21.3 an attacker can cause invalid memory reads during GSS message token handling by sending message tokens with invalid length fields.

Issue summary: An application trying to decrypt CMS messages encrypted using password based encryption can trigger an out-of-bounds read and write.

Impact summary: This out-of-bounds read may trigger a crash which leads to Denial of Service for an application. The out-of-bounds write can cause a memory corruption which can have various consequences including a Denial of Service or Execution of attacker-supplied code.

Although the consequences of a successful exploit of this vulnerability could be severe, the probability that the attacker would be able to perform it is low. Besides, password based (PWRI) encryption support in CMS messages is very rarely used. For that reason the issue was assessed as Moderate severity according to our Security Policy.

The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue, as the CMS implementation is outside the OpenSSL FIPS module boundary.

Impact A memory corruption bug(Heap overflow) in the FreeType font rendering library.

This can be exploited by attackers to execute arbitrary code by using specially crafted fonts with embedded PNG images .

As per https://www.secpod.com/blog/chrome-zero-day-under-active-exploitation-patch-now/

Google is aware of reports that an exploit for CVE-2020-15999 exists in the wild.

Patches Upgrade to 85.3.130 or higher

References - https://www.secpod.com/blog/chrome-zero-day-under-active-exploitation-patch-now/ - https://www.zdnet.com/article/google-releases-chrome-security-update-to-patch-actively-exploited-zero-day/ - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15999 - https://magpcss.org/ceforum/viewtopic.php?f=10&t=17942

To review the CEF/Chromium patch see https://bitbucket.org/chromiumembedded/cef/commits/cd6cbe008b127990036945fb75e7c2c1594ab10d

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

tls: fix handling of zero-length records on the rxlist

Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record

If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rxlist. Next recvmsg() will pick it up from there.

Queuing the skb to rxlist after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length).

Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rxlist, and it's zero length.

Expat (aka libexpat) before 2.4.4 has a signed integer overflow in XMLGetBuffer, for configurations with a nonzero XMLCONTEXTBYTES.

addBinding in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow.

Chromium: CVE-2023-2136 Integer overflow in Skia

An issue was discovered in libexif before 0.6.22. Several buffer over-reads in EXIF MakerNote handling could lead to information disclosure and crashes. This is different from CVE-2020-0093.

Heap-based buffer overflow in dnsmasq before 2.78 allows remote attackers to cause a denial of service (crash) or execute arbitrary code via a crafted DNS response.

libjwt 1.15.3 uses strcmp (which is not constant time) to verify authentication, which makes it easier to bypass authentication via a timing side channel.

gpg-key2ps in signing-party 1.1.x and 2.x before 2.10-1 contains an unsafe shell call enabling shell injection via a User ID.

OpenConnect 8.09 has a buffer overflow, causing a denial of service (application crash) or possibly unspecified other impact, via crafted certificate data to getcertname in gnutls.c.

GNU Emacs through 28.2 allows attackers to execute commands via shell metacharacters in the name of a source-code file, because lib-src/etags.c uses the system C library function in its implementation of the etags program. For example, a victim may use the "etags -u " command (suggested in the etags documentation) in a situation where the current working directory has contents that depend on untrusted input.

An issue was discovered in LemonLDAP::NG through 2.0.8, when NGINX is used. An attacker may bypass URL-based access control to protected Virtual Hosts by submitting a non-normalized URI. This also affects versions before 0.5.2 of the "Lemonldap::NG handler for Node.js" package.

Apache Shiro before 1.5.2, when using Apache Shiro with Spring dynamic controllers, a specially crafted request may cause an authentication bypass.

The kramdown gem before 2.3.0 for Ruby processes the template option inside Kramdown documents by default, which allows unintended read access (such as template="/etc/passwd") or unintended embedded Ruby code execution (such as a string that begins with template="string://<%= ). NOTE: kramdown is used in Jekyll, GitLab Pages, GitHub Pages, and Thredded Forum.

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

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

libceph: fix invalid accesses to cephconnectionv1info

There is a place where generic code in messenger.c is reading and another place where it is writing to con->v1 union member without checking that the union member is active (i.e. msgr1 is in use).

On 64-bit systems, con->v1.authretry overlaps with con->v2.outiter, so such a read is almost guaranteed to return a bogus value instead of 0 when msgr2 is in use. This ends up being fairly benign because the side effect is just the invalidation of the authorizer and successive fetching of new tickets.

con->v1.connectseq overlaps with con->v2.connbufs and the fact that it's being written to can cause more serious consequences, but luckily it's not something that happens often.

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

ksmbd: fix PreauhHashValue race condition

If client send multiple session setup requests to ksmbd, PreauhHashValue race condition could happen. There is no need to free sess->PreauhHashValue at session setup phase. It can be freed together with session at connection termination phase.

bnxten: Set DMA unmap len correctly for XDPREDIRECT

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

smb: client: fix use-after-free in cifsoplockbreak

A race condition can occur in cifsoplockbreak() leading to a use-after-free of the cinode structure when unmounting:

cifsoplockbreak() cifsFileInfoput(cfile) cifsFileInfoputfinal() cifssbdeactive() [last ref, start releasing sb] killsb() killanonsuper() genericshutdownsuper() evictinodes() disposelist() evict() destroyinode() callrcu(&inode->ircu, icallback) spinlock(&cinode->openfilelock) <- OK [later] icallback() cifsfreeinode() kmemcachefree(cinode) spinunlock(&cinode->openfilelock) <- UAF cifsdoneoplockbreak(cinode) <- UAF

The issue occurs when umount has already released its reference to the superblock. When cifsFileInfoput() calls cifssbdeactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifsoplockbreak() continues to access the cinode after this point, resulting in use-after-free.

Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.

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

smb: client: fix use-after-free in cryptmessage when using async crypto

The CVE-2024-50047 fix removed asynchronous crypto handling from cryptmessage(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:

cryptmessage() // Allocate the creq buffer containing the req creq = smb2getaeadreq(..., &req);

// Async encryption returns -EINPROGRESS immediately rc = enc ? cryptoaeadencrypt(req) : cryptoaeaddecrypt(req);

// Free creq while async operation is still in progress kvfreesensitive(creq, ...);

Hardware crypto modules often implement async AEAD operations for performance. When cryptoaeadencrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without cryptowaitreq(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.

This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.

The issue occurs because cryptoallocaead() with mask=0 doesn't guarantee synchronous operation. Even without CRYPTOALGASYNC in the mask, async implementations can be selected.

Fix by restoring the async crypto handling: - DECLARECRYPTOWAIT(wait) for completion tracking - aeadrequestsetcallback() for async completion notification - cryptowaitreq() to wait for operation completion

This ensures the request buffer isn't freed until the crypto operation completes, whether synchronous or asynchronous, while preserving the CVE-2024-50047 fix.

btrfs: fix a race between renames and directory logging