Last updated 24 September 2025

A flaw was found in the Netfilter module in the Linux kernel. The problem is in the nftbyteordereval() function where the code is iterating through a loop and writing to dst[0], dst[1], dst[2] and so on. On each iteration 8 bytes get written, but dst[] is an array of u32 so each element only has space for 4 bytes. That means that every iteration overwrites part of the previous element.

Upstream commit: https://github.com/torvalds/linux/commit/c301f0981fdd3fd1ffac6836b423c4d7a8e0eb63

Last updated 25 August 2025

Catastrophic backtracking vulnerability was found in Python. Exploitation of a regular expression in difflib.ISLINEJUNK method in servers that use difflib can lead to denial of service.

Upstream issue:

https://bugs.python.org/issue32981

An issue was discovered in FasterXML jackson-databind prior to 2.7.9.4, 2.8.11.2, and 2.9.6. When Default Typing is enabled (either globally or for a specific property), the service has the Oracle JDBC jar in the classpath, and an attacker can provide an LDAP service to access, it is possible to make the service execute a malicious payload.

Accounts. The issue was addressed with improved checks.

libexpat could allow a remote attacker to obtain sensitive information, caused by improper handling of XML external entity (XXE) declarations by the XMLExternalEntityParserCreate function. By using a specially crafted XML content, a remote attacker could exploit this vulnerability to obtain sensitive information, and use this information to launch further attacks against the affected system.

Accounts. The issue was addressed with improved checks.

Last updated 24 July 2024

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

clk: Get runtime PM before walking tree during disableunused

Doug reported [1] the following hung task:

INFO: task swapper/0:1 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call trace: switchto+0xf4/0x1f4 schedule+0x418/0xb80 schedule+0x5c/0x10c rpmresume+0xe0/0x52c rpmresume+0x178/0x52c pmruntimeresume+0x58/0x98 clkpmruntimeget+0x30/0xb0 clkdisableunusedsubtree+0x58/0x208 clkdisableunusedsubtree+0x38/0x208 clkdisableunusedsubtree+0x38/0x208 clkdisableunusedsubtree+0x38/0x208 clkdisableunusedsubtree+0x38/0x208 clkdisableunused+0x4c/0xe4 dooneinitcall+0xcc/0x2d8 doinitcalllevel+0xa4/0x148 doinitcalls+0x5c/0x9c dobasicsetup+0x24/0x30 kernelinitfreeable+0xec/0x164 kernelinit+0x28/0x120 retfromfork+0x10/0x20 INFO: task kworker/u16:0:9 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008 Workqueue: eventsunbound deferredprobeworkfunc Call trace: switchto+0xf4/0x1f4 schedule+0x418/0xb80 schedule+0x5c/0x10c schedulepreemptdisabled+0x2c/0x48 mutexlock+0x238/0x488 mutexlockslowpath+0x1c/0x28 mutexlock+0x50/0x74 clkpreparelock+0x7c/0x9c clkcorepreparelock+0x20/0x44 clkprepare+0x24/0x30 clkbulkprepare+0x40/0xb0 mdssruntimeresume+0x54/0x1c8 pmgenericruntimeresume+0x30/0x44 genpdruntimeresume+0x68/0x7c genpdruntimeresume+0x108/0x1f4 rpmcallback+0x84/0x144 rpmcallback+0x30/0x88 rpmresume+0x1f4/0x52c rpmresume+0x178/0x52c pmruntimeresume+0x58/0x98 deviceattach+0xe0/0x170 deviceinitialprobe+0x1c/0x28 busprobedevice+0x3c/0x9c deviceadd+0x644/0x814 mipidsideviceregisterfull+0xe4/0x170 devmmipidsideviceregisterfull+0x28/0x70 tisnbridgeprobe+0x1dc/0x2c0 auxiliarybusprobe+0x4c/0x94 reallyprobe+0xcc/0x2c8 driverprobedevice+0xa8/0x130 driverprobedevice+0x48/0x110 deviceattachdriver+0xa4/0xcc busforeachdrv+0x8c/0xd8 deviceattach+0xf8/0x170 deviceinitialprobe+0x1c/0x28 busprobedevice+0x3c/0x9c deferredprobeworkfunc+0x9c/0xd8 processonework+0x148/0x518 workerthread+0x138/0x350 kthread+0x138/0x1e0 retfromfork+0x10/0x20

The first thread is walking the clk tree and calling clkpmruntimeget() to power on devices required to read the clk hardware via struct clkops::isenabled(). This thread holds the clk preparelock, and is trying to runtime PM resume a device, when it finds that the device is in the process of resuming so the thread schedule()s away waiting for the device to finish resuming before continuing. The second thread is runtime PM resuming the same device, but the runtime resume callback is calling clkprepare(), trying to grab the preparelock waiting on the first thread.

This is a classic ABBA deadlock. To properly fix the deadlock, we must never runtime PM resume or suspend a device with the clk preparelock held. Actually doing that is near impossible today because the global preparelock would have to be dropped in the middle of the tree, the device runtime PM resumed/suspended, and then the preparelock grabbed again to ensure consistency of the clk tree topology. If anything changes with the clk tree in the meantime, we've lost and will need to start the operation all over again.

Luckily, most of the time we're simply incrementing or decrementing the runtime PM count on an active device, so we don't have the chance to schedule away with the preparelock held. Let's fix this immediate problem that can be ---truncated---

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

tun: limit printing rate when illegal packet received by tun dev

The Linux kernel CVE team has assigned CVE-2024-27013 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050149-CVE-2024-27013-2c26@gregkh/T

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

init/main.c: Fix potential staticcommandline memory overflow

The Linux kernel CVE team has assigned CVE-2024-26988 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050143-CVE-2024-26988-c304@gregkh/T

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.

A heap use-after-free issue has been identified in SQLite in the jsonParseAddNodeArray() function in sqlite3.c. This flaw allows a local attacker to leverage a victim to pass specially crafted malicious input to the application, potentially causing a crash and leading to a denial of service.

A vulnerability was found in GnuTLS, where a cockpit (which uses gnuTLS) rejects a certificate chain with distributed trust. This issue occurs when validating a certificate chain with cockpit-certificate-ensure. This flaw allows an unauthenticated, remote client or attacker to initiate a denial of service attack.

Summary

Terrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it.

Mitigations

To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes.

Warning: To take effect, both the client and server must support this countermeasure.

As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available.

Details

The SSH specifications of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com MACs) are vulnerable against an arbitrary prefix truncation attack (a.k.a. Terrapin attack). This allows for an extension negotiation downgrade by stripping the SSHMSGEXTINFO sent after the first message after SSHMSGNEWKEYS, downgrading security, and disabling attack countermeasures in some versions of OpenSSH. When targeting Encrypt-then-MAC, this attack requires the use of a CBC cipher to be practically exploitable due to the internal workings of the cipher mode. Additionally, this novel attack technique can be used to exploit previously unexploitable implementation flaws in a Man-in-the-Middle scenario.

The attack works by an attacker injecting an arbitrary number of SSHMSGIGNORE messages during the initial key exchange and consequently removing the same number of messages just after the initial key exchange has concluded. This is possible due to missing authentication of the excess SSHMSGIGNORE messages and the fact that the implicit sequence numbers used within the SSH protocol are only checked after the initial key exchange.

In the case of ChaCha20-Poly1305, the attack is guaranteed to work on every connection as this cipher does not maintain an internal state other than the message's sequence number. In the case of Encrypt-Then-MAC, practical exploitation requires the use of a CBC cipher; while theoretical integrity is broken for all ciphers when using this mode, message processing will fail at the application layer for CTR and stream ciphers.

For more details see https://terrapin-attack.com.

Impact

This attack targets the specification of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com), which are widely adopted by well-known SSH implementations and can be considered de-facto standard. These algorithms can be practically exploited; however, in the case of Encrypt-Then-MAC, we additionally require the use of a CBC cipher. As a consequence, this attack works against all well-behaving SSH implementations supporting either of those algorithms and can be used to downgrade (but not fully strip) connection security in case SSH extension negotiation (RFC8308) is supported. The attack may also enable attackers to exploit certain implementation flaws in a man-in-the-middle (MitM) scenario.

An issue was discovered in GNOME GLib before 2.78.5, and 2.79.x and 2.80.x before 2.80.1. When a GDBus-based client subscribes to signals from a trusted system service such as NetworkManager on a shared computer, other users of the same computer can send spoofed D-Bus signals that the GDBus-based client will wrongly interpret as having been sent by the trusted system service. This could lead to the GDBus-based client behaving incorrectly, with an application-dependent impact.

A flaw was found in ipv4senddestunreach() due to NULL pointer derefence due to a missing edge-case check.

A flaw was found in the XFRM subsystem in the Linux kernel. The specific flaw exists within the processing of state filters, which can result in a read past the end of an allocated buffer. This flaw allows a local privileged (CAPNETADMIN) attacker to trigger an out-of-bounds read, potentially leading to an information disclosure.

A flaw was found in the Netfilter subsystem in the Linux kernel. The sctpmtcheck did not validate the flagcount field. This flaw allows a local privileged (CAPNETADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure.

A flaw was found in the Netfilter subsystem in the Linux kernel. The xtu32 module did not validate the fields in the xtu32 structure. This flaw allows a local privileged attacker to trigger an out-of-bounds read by setting the size fields with a value beyond the array boundaries, leading to a crash or information disclosure.

A flaw was found in the Netfilter subsystem in the Linux kernel. The nfnlosfaddcallback function did not validate the user mode controlled optnum field. This flaw allows a local privileged (CAPNETADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure.

Airport. A permissions issue was addressed with improved redaction of sensitive information.

Last updated 18 March 2026

An assertion failure in dbus-daemon when a privileged Monitoring connection (dbus-monitor, busctl monitor, gdbus monitor or similar) is active, and a message from the bus driver cannot be delivered to a client connection due to <deny> rules or outgoing message quota. This is a denial of service if triggered maliciously by a local attacker

In other words, if a privileged user with control over the dbus-daemon is using the org.freedesktop.DBus.Monitoring interface to monitor message bus traffic, then an unprivileged user with the ability to connect to the same dbus-daemon can cause a dbus-daemon crash under some circumstances.

Vulnerable versions:

1.15.x before 1.15.6 1.14.x before 1.14.8 1.12.x before 1.12.28 most end-of-life versions since 1.9.x

Fixed versions:

all since 1.15.6 1.14.x since 1.14.8 1.12.x since 1.12.28

Not vulnerable: end-of-life versions 1.8.x or older do not contain the affected code path.

https://gitlab.freedesktop.org/dbus/dbus/-/issues/457 https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1908636.html

Last updated 24 July 2024

cURL libcurl could allow a remote attacker to bypass security restrictions, caused by a mixed case flaw when curl is built without PSL support. By sending a specially crafted request, an attacker could exploit this vulnerability to allow a HTTP server to set "super cookies" in curl.

HTTP/2 Rapid reset attack The HTTP/2 protocol allows clients to indicate to the server that a previous stream should be canceled by sending a RSTSTREAM frame. The protocol does not require the client and server to coordinate the cancellation in any way, the client may do it unilaterally. The client may also assume that the cancellation will take effect immediately when the server receives the RSTSTREAM frame, before any other data from that TCP connection is processed.

Abuse of this feature is called a Rapid Reset attack because it relies on the ability for an endpoint to send a RSTSTREAM frame immediately after sending a request frame, which makes the other endpoint start working and then rapidly resets the request. The request is canceled, but leaves the HTTP/2 connection open.

The HTTP/2 Rapid Reset attack built on this capability is simple: The client opens a large number of streams at once as in the standard HTTP/2 attack, but rather than waiting for a response to each request stream from the server or proxy, the client cancels each request immediately.

The ability to reset streams immediately allows each connection to have an indefinite number of requests in flight. By explicitly canceling the requests, the attacker never exceeds the limit on the number of concurrent open streams. The number of in-flight requests is no longer dependent on the round-trip time (RTT), but only on the available network bandwidth.

In a typical HTTP/2 server implementation, the server will still have to do significant amounts of work for canceled requests, such as allocating new stream data structures, parsing the query and doing header decompression, and mapping the URL to a resource. For reverse proxy implementations, the request may be proxied to the backend server before the RSTSTREAM frame is processed. The client on the other hand paid almost no costs for sending the requests. This creates an exploitable cost asymmetry between the server and the client.

Multiple software artifacts implementing HTTP/2 are affected. This advisory was originally ingested from the swift-nio-http2 repo advisory and their original conent follows.

swift-nio-http2 specific advisory swift-nio-http2 is vulnerable to a denial-of-service vulnerability in which a malicious client can create and then reset a large number of HTTP/2 streams in a short period of time. This causes swift-nio-http2 to commit to a large amount of expensive work which it then throws away, including creating entirely new Channels to serve the traffic. This can easily overwhelm an EventLoop and prevent it from making forward progress.

swift-nio-http2 1.28 contains a remediation for this issue that applies reset counter using a sliding window. This constrains the number of stream resets that may occur in a given window of time. Clients violating this limit will have their connections torn down. This allows clients to continue to cancel streams for legitimate reasons, while constraining malicious actors.

Accessibility. A privacy issue was addressed with improved private data redaction for log entries.

A vulnerability was found in SQLite SQLite3 up to 3.43.0 and classified as critical. This issue affects the function sessionReadRecord of the file ext/session/sqlite3session.c of the component make alltest Handler. The manipulation leads to heap-based buffer overflow. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-248999.