CVE-2024-42516 - this is the "complete" fix for the CVE-2023-38709 response splitting issue. The patch issued upstream for CVE-2023-38709 did not fix the vulnerability.

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

mm: fix zswap writeback race condition

The zswap writeback mechanism can cause a race condition resulting in memory corruption, where a swapped out page gets swapped in with data that was written to a different page.

The race unfolds like this: 1. a page with data A and swap offset X is stored in zswap 2. page A is removed off the LRU by zpool driver for writeback in zswap-shrink work, data for A is mapped by zpool driver 3. user space program faults and invalidates page entry A, offset X is considered free 4. kswapd stores page B at offset X in zswap (zswap could also be full, if so, page B would then be IOed to X, then skip step 5.) 5. entry A is replaced by B in tree->rbroot, this doesn't affect the local reference held by zswap-shrink work 6. zswap-shrink work writes back A at X, and frees zswap entry A 7. swapin of slot X brings A in memory instead of B

The fix: Once the swap page cache has been allocated (case ZSWAPSWAPCACHENEW), zswap-shrink work just checks that the local zswapentry reference is still the same as the one in the tree. If it's not the same it means that it's either been invalidated or replaced, in both cases the writeback is aborted because the local entry contains stale data.

Reproducer: I originally found this by running stress overnight to validate my work on the zswap writeback mechanism, it manifested after hours on my test machine. The key to make it happen is having zswap writebacks, so whatever setup pumps /sys/kernel/debug/zswap/writtenbackpages should do the trick.

In order to reproduce this faster on a vm, I setup a system with ~100M of available memory and a 500M swap file, then running stress --vm 1 --vm-bytes 300000000 --vm-stride 4000 makes it happen in matter of tens of minutes. One can speed things up even more by swinging /sys/module/zswap/parameters/maxpoolpercent up and down between, say, 20 and 1; this makes it reproduce in tens of seconds. It's crucial to set --vm-stride to something other than 4096 otherwise stress won't realize that memory has been corrupted because all pages would have the same data.

Last updated 25 February 2025

Android contains an unspecified vulnerability in the kernel that allows for remote code execution. This vulnerability resides in Linux Kernel and could impact other products, including but not limited to Android OS.

Accessibility. An authentication issue was addressed with improved state management.

Accessibility. An authentication issue was addressed with improved state management.

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).

Last updated 20 August 2025

A null pointer dereference vulnerability was discovered in the libxml2. The issue occurs in the xmlSchematronFormatReport function when processing incorrect XPath expressions in Schematron schema reports, leading to undefined behavior and potential crashes.

Accounts. The issue was addressed with improved checks.

glibc is vulnerable to a denial of service, caused by a memory allocation failure when the Name Service Cache Daemon's (nscd) netgroup cache uses the xmalloc or xrealloc functions. A local attacker could exploit this vulnerability to terminate the daemon.

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

perf/aux: Fix AUX buffer serialization

Ole reported that event->mmapmutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it.

Note that in the lock order comment the perfevent::mmapmutex order was already wrong, that is, it nesting under mmaplock is not new with this patch.

A denial-of-service (DoS) attack was found in the mlx5 driver in the Linux kernel. A KVM guest VM using virtio-net can crash the host by sending a short packet (i.e. size < ETHHLEN). The packet may traverse through vhost-net, macvtap and vlan without any validation/drop. When this packet is presented to mlx5 driver on the host side, the kernel panic happens since mlx5core assumes the frame size is always >= ETHHLEN.

This vulnerability affects both drivers/net/tun.c and drivers/net/tap.c. CVE-2024-41091 has been assigned to the TUN side of the issue.

Reference: https://www.openwall.com/lists/oss-security/2024/07/24/4

A denial-of-service (DoS) attack was found in the mlx5 driver in the Linux kernel. A KVM guest VM using virtio-net can crash the host by sending a short packet (i.e. size < ETHHLEN). The packet may traverse through vhost-net, macvtap and vlan without any validation/drop. When this packet is presented to mlx5 driver on the host side, the kernel panic happens, since mlx5core assumes the frame size is always >= ETHHLEN.

This vulnerability affects both drivers/net/tun.c and drivers/net/tap.c. CVE-2024-41090 has been assigned to the TAP side of the issue.

Reference: https://www.openwall.com/lists/oss-security/2024/07/24/4

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

afunix: Fix garbage collector racing against connect()

Garbage collector does not take into account the risk of embryo getting enqueued during the garbage collection. If such embryo has a peer that carries SCMRIGHTS, two consecutive passes of scanchildren() may see a different set of children. Leading to an incorrectly elevated inflight count, and then a dangling pointer within the gcinflightlist.

sockets are AFUNIX/SOCKSTREAM S is an unconnected socket L is a listening in-flight socket bound to addr, not in fdtable V's fd will be passed via sendmsg(), gets inflight count bumped

connect(S, addr) sendmsg(S, [V]); close(V) unixgc() ---------------- ------------------------- -----------

NS = unixcreate1() skb1 = sockwmalloc(NS) L = unixfindother(addr) unixstatelock(L) unixpeer(S) = NS // V count=1 inflight=0

NS = unixpeer(S) skb2 = sockalloc() skbqueuetail(NS, skb2[V])

// V became in-flight // V count=2 inflight=1

close(V)

// V count=1 inflight=1 // GC candidate condition met

for u in gcinflightlist: if (totalrefs == inflightrefs) add u to gccandidates

// gccandidates={L, V}

for u in gccandidates: scanchildren(u, decinflight)

// embryo (skb1) was not // reachable from L yet, so V's // inflight remains unchanged skbqueuetail(L, skb1) unixstateunlock(L) for u in gccandidates: if (u.inflight) scanchildren(u, incinflightmovetail)

// V count=1 inflight=2 (!)

If there is a GC-candidate listening socket, lock/unlock its state. This makes GC wait until the end of any ongoing connect() to that socket. After flipping the lock, a possibly SCM-laden embryo is already enqueued. And if there is another embryo coming, it can not possibly carry SCMRIGHTS. At this point, unixinflight() can not happen because unixgclock is already taken. Inflight graph remains unaffected.

Allocation of resources for multipart headers with insufficient limits enabled a DoS vulnerability in Apache Commons FileUpload.

This issue affects Apache Commons FileUpload: from 1.0 before 1.6; from 2.0.0-M1 before 2.0.0-M4.

Users are recommended to upgrade to versions 1.6 or 2.0.0-M4, which fix the issue.

HTTP/2 (including DNS over HTTPS) contains a design flaw and is vulnerable to "MadeYouReset" DoS attack through HTTP/2 control frames Vulnerabilities.

A stack overflow vulnerability exists in the libexpat library due to the way it handles recursive entity expansion in XML documents. When parsing an XML document with deeply nested entity references, libexpat can be forced to recurse indefinitely, exhausting the stack space and causing a crash. This issue could lead to denial of service (DoS) or, in some cases, exploitable memory corruption, depending on the environment and library usage.

A type confusion vulnerability was found in OpenSSL when OpenSSL X.400 addresses processing inside an X.509 GeneralName. When CRL checking is enabled (for example, the application sets the X509VFLAGCRLCHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a memcmp call, enabling them to read memory contents or cause a denial of service. In most cases, the attack requires the attacker to provide both the certificate chain and CRL, of which neither needs a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. In this case, this vulnerability is likely only to affect applications that have implemented their own functionality for retrieving CRLs over a network.

A use-after-free vulnerability was found in OpenSSL's BIOnewNDEF function. The public API function BIOnewNDEF is a helper function used for streaming ASN.1 data via a BIO. It is primarily used internally by OpenSSL to support the SMIME, CMS, and PKCS7 streaming capabilities, but it may also be called directly by end-user applications. The function receives a BIO from the caller, prepends a new BIOfasn1 filter BIO onto the front of it to form a BIO chain, and then returns the new head of the BIO chain to the caller. Under certain conditions. For example, if a CMS recipient public key is invalid, the new filter BIO is freed, and the function returns a NULL result indicating a failure. However, in this case, the BIO chain is not properly cleaned up, and the BIO passed by the caller still retains internal pointers to the previously freed filter BIO. If the caller then calls BIOpop() on the BIO, a use-after-free will occur, possibly resulting in a crash.

A double-free vulnerability was found in OpenSSL's PEMreadbioex function. The function PEMreadbioex() reads a PEM file from a BIO and parses and decodes the "name" (for example, "CERTIFICATE"), any header data, and the payload data. If the function succeeds, then the "nameout," "header," and "data" arguments are populated with pointers to buffers containing the relevant decoded data. The caller is responsible for freeing those buffers. Constructing a PEM file that results in 0 bytes of payload data is possible. In this case, PEMreadbioex() will return a failure code but will populate the header argument with a pointer to a freed buffer. A double-free will occur if the caller also frees this buffer. This will most likely lead to a crash. This could be exploited by an attacker who can supply malicious PEM files for parsing to achieve a denial of service attack.

Prior to Apache HTTP Server 2.4.55, a malicious backend can cause the response headers to be truncated early, resulting in some headers being incorporated into the response body. If the later headers have any security purpose, they will not be interpreted by the client.

A flaw was found in Apache Commons FileUpload, where it does not limit the number of parts being processed in a request. This issue may allow an attacker to use a malicious upload or series of uploads to trigger a denial of service. While Red Hat Satellite relies upon Apache Tomcat, it does not directly ship it. Tomcat is shipped with Red Hat Enterprise Linux and consumed by the Candlepin component of Satellite. Red Hat Satellite users are therefore advised to check the impact state of Red Hat Enterprise Linux, since any necessary fixes will be distributed through the platform.

A flaw was found in linux-pam. The pamnamespace module may improperly handle user-controlled paths, allowing local users to exploit symlink attacks and race conditions to elevate their privileges to root. This CVE provides a "complete" fix for CVE-2025-6020.

CVE-2025-52434Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in Apache Tomcat when using the APR/Native connector. This was particularly noticeable with client initiated closes of HTTP/2 connections. This issue affects Apache Tomcat: from 9.0.0.M1 through 9.0.106. Users are recommended to upgrade to version 9.0.107, which fixes the issue. CVE-2025-53506Uncontrolled Resource Consumption vulnerability in Apache Tomcat if an HTTP/2 client did not acknowledge the initial settings frame that reduces the maximum permitted concurrent streams. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.8, from 10.1.0-M1 through 10.1.42, from 9.0.0.M1 through 9.0.106. Users are recommended to upgrade to version 11.0.9, 10.1.43 or 9.0.107, which fix the issue.

For some unlikely configurations of multipart upload, an Integer Overflow vulnerability in Apache Tomcat could lead to a DoS via bypassing of size limits.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.8, from 10.1.0-M1 through 10.1.42, from 9.0.0.M1 through 9.0.106.

Users are recommended to upgrade to version 11.0.9, 10.1.43 or 9.0.107, which fix the issue.

Relative Path Traversal vulnerability in Apache Tomcat.

The fix for bug 60013 introduced a regression where the rewritten URL was normalized before it was decoded. This introduced the possibility that, for rewrite rules that rewrite query parameters to the URL, an attacker could manipulate the request URI to bypass security constraints including the protection for /WEB-INF/ and /META-INF/. If PUT requests were also enabled then malicious files could be uploaded leading to remote code execution. PUT requests are normally limited to trusted users and it is considered unlikely that PUT requests would be enabled in conjunction with a rewrite that manipulated the URI.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.10, from 10.1.0-M1 through 10.1.44, from 9.0.0.M11 through 9.0.108.

The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.6 though 8.5.100. Other, older, EOL versions may also be affected. Users are recommended to upgrade to version 11.0.11 or later, 10.1.45 or later or 9.0.109 or later, which fix the issue.

Accessibility. A logging issue was addressed with improved data redaction.

A vulnerability was found in GnuTLS. The response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from the response times of ciphertexts with correct PKCS#1 v1.5 padding. This issue may allow a remote attacker to perform a timing side-channel attack in the RSA-PSK key exchange, potentially leading to the leakage of sensitive data. CVE-2024-0553 is designated as an incomplete resolution for CVE-2023-5981.

Last updated 24 September 2025