A vulnerability was found in libxml2. Processing certain sch:name elements from the input XML file can trigger a memory corruption issue. This flaw allows an attacker to craft a malicious XML input file that can lead libxml to crash, resulting in a denial of service or other possible undefined behavior due to sensitive data being corrupted in memory.

A Heap Use After Free (UAF) vulnerability was discovered in the Schematron in the libxml2. The issue arises in the xmlSchematronGetNode function when processing XPath expressions in Schematron schema elements <sch:name path="..."/>, where a pointer to freed memory is returned and then accessed, leading to undefined behavior and potential crashes.

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.

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

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.

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

sched/membarrier: reduce the ability to hammer on sysmembarrier

On some systems, sysmembarrier can be very expensive, causing overall slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the ability for this to be called at too high of a frequency and saturate the machine.

An unspecified vulnerability in Java SE related to the Libraries component could allow an unauthenticated attacker to cause no confidentiality impact, low integrity impact, and no availability impact.

Apache Tomcat 10.0.0-M1 to 10.0.6, 9.0.0.M1 to 9.0.46 and 8.5.0 to 8.5.66 did not correctly parse the HTTP transfer-encoding request header in some circumstances leading to the possibility to request smuggling when used with a reverse proxy. Specifically: - Tomcat incorrectly ignored the transfer encoding header if the client declared it would only accept an HTTP/1.0 response; - Tomcat honoured the identify encoding; and - Tomcat did not ensure that, if present, the chunked encoding was the final encoding.

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

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

Last updated 11 July 2025

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 the Linux kernel, the following vulnerability has been resolved:

tls: separate no-async decryption request handling from async

If we're not doing async, the handling is much simpler. There's no reference counting, we just need to wait for the completion to wake us up and return its result.

We should preferably also use a separate cryptowait. I'm not seeing a UAF as I did in the past, I think aec7961916f3 ("tls: fix race between async notify and socket close") took care of it.

This will make the next fix easier.

Last updated 20 August 2025

In libxml2 before 2.10.4, parsing of certain invalid XSD schemas can lead to a NULL pointer dereference and subsequently a segfault. This occurs in xmlSchemaFixupComplexType in xmlschemas.c.

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.

ping in iputils before 20250602 allows a denial of service

A flaw was found in GnuTLS, which relies on libtasn1 for ASN.1 data processing. Due to an inefficient algorithm in libtasn1, decoding certain DER-encoded certificate data can take excessive time, leading to increased resource consumption. This flaw allows a remote attacker to send a specially crafted certificate, causing GnuTLS to become unresponsive or slow, resulting in a denial-of-service condition.

Issue summary: A timing side-channel which could potentially allow recovering the private key exists in the ECDSA signature computation.

Impact summary: A timing side-channel in ECDSA signature computations could allow recovering the private key by an attacker. However, measuring the timing would require either local access to the signing application or a very fast network connection with low latency.

There is a timing signal of around 300 nanoseconds when the top word of the inverted ECDSA nonce value is zero. This can happen with significant probability only for some of the supported elliptic curves. In particular the NIST P-521 curve is affected. To be able to measure this leak, the attacker process must either be located in the same physical computer or must have a very fast network connection with low latency. For that reason the severity of this vulnerability is Low.

Issue summary: Some non-default TLS server configurations can cause unbounded memory growth when processing TLSv1.3 sessions

Accounts. The issue was addressed with improved checks.

Jinja is an extensible templating engine. The xmlattr filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, /, >, or =, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the xmlattr filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting values as user input continues to be safe. This vulnerability is fixed in 3.1.4.

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.

i40e: fix idx validation in config queues msg

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.