{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-image-7.0.0-38-generic", "linux-main-modules-zfs-7.0.0-38-generic", "linux-modules-7.0.0-38-generic" ], "removed": [ "linux-image-7.0.0-34-generic", "linux-main-modules-zfs-7.0.0-34-generic", "linux-modules-7.0.0-34-generic" ], "diff": [ "libssl3t64", "linux-image-virtual", "openssl", "openssl-provider-legacy", "python3-jwt", "python3-requests" ] } }, "diff": { "deb": [ { "name": "libssl3t64", "from_version": { "source_package_name": "openssl", "source_package_version": "3.5.5-1ubuntu3.5", "version": "3.5.5-1ubuntu3.5" }, "to_version": { "source_package_name": "openssl", "source_package_version": "3.5.5-1ubuntu3.7", "version": "3.5.5-1ubuntu3.7" }, "cves": [ { "cve": "CVE-2026-42772", "url": "https://ubuntu.com/security/CVE-2026-42772", "cve_description": "Issue summary: The QUIC stream reassembly algorithm performance deteriorates progressively as packets are arriving out of order. The worst case has a quadratic complexity proportional to the number of stream frames kept in the buffer for the received stream data. Impact summary: A remote QUIC peer that completes the handshake can create a connection-scoped CPU pressure and potentially a Denial of Service using compliant STREAM frames inside the advertised receive window, with low attacker bandwidth. CWE: CWE-407: Inefficient Algorithmic Complexity Description: OpenSSL manages received QUIC stream fragments using a doubly-linked list. While it optimizes for append operations (at the end of the list), it falls back to a head-to-tail linear search for any fragment that does not immediately follow the current `tail`. By manipulating the sequence of offsets, an attacker can force the server to perform O(n^2) operations, consuming excessive CPU time for the QUIC process. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54873", "url": "https://ubuntu.com/security/CVE-2026-54873", "cve_description": "Issue summary: QUIC process may keep memory for QUIC packet buffer for much longer period than necessary. Impact summary: Remote peer can exploit this vulnerability by sending maliciously crafted packets, making the local QUIC stack to keep the memory for packet buffers allocated. The time for which the memory remains allocated is entirely under the control of the potentially malicious remote peer. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: To save copy operation from the packet buffer to the stream reassemble buffer the QUIC stack leaves the stream data on the packet buffer waiting to be copied to a buffer provided by the local receiving application. The QUIC stack releases a reference to the packet buffer only after the data are copied to the application buffer. This design is more efficient for legitimate data transfers but enables an attacker to allocate a lot more memory than actually required by the data kept in the receiving stream buffer. To mitigate the vulnerability, the QUIC stack now calculates and monitors memory overhead for every stream. The memory overhead for a single stream frame is calculated as a difference between the size of the whole packet that carries the stream frame and the size of the stream frame itself. The memory overhead for a single stream frame is added to the total (cumulative) memory overhead QUIC stack keeps for each stream. Once the cumulative memory overhead exceeds 64kB, the QUIC stack moves the stream frame data from the packet buffer to the stream buffer, starting with the next packet received. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-35189", "url": "https://ubuntu.com/security/CVE-2026-35189", "cve_description": "Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-35191", "url": "https://ubuntu.com/security/CVE-2026-35191", "cve_description": "Issue summary: The OpenSSL QUIC server, when configured to not preform address validation, can be forced to count incoming packets multiple times in its unvalidated credit computation, leading to a violation of the RFC 9000 unvalidated connection amplification limit of 3 times the amount of data received. Impact summary: A remote attacker able to spoof packets to a server using the OpenSSL QUIC implementation might use the server for an amplification of a DDoS attack. CWE: CWE-440: Expected Behavior Violation Description: OpenSSL's QUIC stack, when operating as a server, enforces client address validation (RFC 9000, Section 8), to confirm the peer address is not used for a traffic amplification attack. If this feature is disabled on the server, the QUIC stack limits the amount of server data that can be sent to 3 times the amount of data received from the peer address, until such time as the TLS handshake is completed. The OpenSSL QUIC server, when operating in non-validation mode, adds the length of the whole datagram received to the unvalidated credit limit when processing each QUIC packet in the datagram. A remote peer may, after establishing a connection with an initial client hello frame, send a subsequent datagram containing multiple QUIC packets, leading the server to account the entire datagram length for each packet in the datagram, resulting in the server believing that the peer has sent more data than it actually has, thereby violating the 3x amplification limit mandated by the RFC. FIPS impact: no As the QUIC stack lives outside the FIPS module boundary, no FIPS modules are affected by this CVE.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54872", "url": "https://ubuntu.com/security/CVE-2026-54872", "cve_description": "Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature operations with curves that do not have a dedicated implementation leaks information about the secret nonce through timing. Impact summary: An attacker able to measure signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: The generic elliptic-curve scalar multiplication used for curves that do not have a dedicated constant-time implementation pads the secret scalar with non-constant-time BIGNUM operations, so the time taken depends on the value of the secret scalar derived from the ECDSA and SM2 nonce. The leak is very small; observing it requires a large number of measurements. The effect is largest for curves whose group order lies on a machine-word boundary, such as brainpoolP384r1. Applications using ECDSA signing over the Brainpool and other generic prime curves, and SM2 signing on platforms that use the generic implementation, are vulnerable to this issue. The NIST curves P-256, P-384 and P-521 use dedicated constant-time implementations and are not affected. FIPS Impact: no The FIPS modules are not affected: the approved NIST curves used in the FIPS provider have dedicated constant-time implementations and do not use the affected code path.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54875", "url": "https://ubuntu.com/security/CVE-2026-54875", "cve_description": "Issue summary: A non-constant-time optimized implementation of scalar point multiplication is used for SM2 private key operations on ARM64 and RISC-V platforms. Impact summary: An attacker able to measure the time taken by, or to observe the cache-line access pattern of SM2 signing or decryption on an affected platform can learn information about the secret scalar. CWE: CWE-208: Observable Timing Discrepancy Description: On ARM64 and RISC-V processors, the SM2 curve uses an optimized scalar multiplication implementation whose conditional branches and table look ups are chosen according to the bits of the secret scalar. The execution time and the cache-access pattern therefore depend on the long-term private key (during SM2 decryption) or the per-signature nonce (during SM2 signature generation), forming a timing and cache side-channel. FIPS Impact: no SM2 is not a FIPS algorithm and the optimized SM2 implementation is not part of the FIPS module. OpenSSL 4.0, 3.6, 3.5 and 3.4 are vulnerable to this issue on AArch64 and RISC-V. OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue. OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3. OpenSSL 3.6 users should upgrade to OpenSSL 3.6.5. OpenSSL 3.5 users should upgrade to OpenSSL 3.5.9. OpenSSL 3.4 users should upgrade to OpenSSL 3.4.8. This issue was reported on 2 May 2026 by Abhinav Agarwal. It was independently reported on 6 June 2026 by Feng Xue. The fix was developed by Igor Ustinov. -- cut (non-publishing metadata for internal use) -- Reported by: Abhinav Agarwal, Feng Xue Fixed by: Igor Ustinov", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-72897", "url": "https://ubuntu.com/security/CVE-2026-72897", "cve_description": "Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch a connection to a different SSL_CTX part way through a handshake may access memory beyond the end of an internal array if the replacement context knows about more provider signature algorithms than the context the connection was created from. Applications which never call SSL_set_SSL_CTX() are not affected. Impact summary: A remote peer may be able to cause a small out-of-bounds read, and in some circumstances a fixed-value out-of-bounds write, on the server heap. This may lead to a Denial of Service. CWE: CWE-787: Out-of-bounds Write Description: A TLS connection records how many certificate slots it has when it is created, taken from the SSL_CTX that created it: the built-in certificate types plus one slot for each provider TLS-SIGALG entry that context was aware of. That count sizes an internal array of per-slot certificate validity flags. An application may replace a connection's SSL_CTX part way through the handshake by calling SSL_set_SSL_CTX(), most commonly from a servername callback in order to serve a different virtual host. Doing so did not refresh the recorded count. A provider signature algorithm's slot index is its position in the list of whichever context resolves it, so if the replacement context is aware of more of them than the original, an algorithm offered by the peer can resolve to an index beyond the end of the array. Processing the peer's signature algorithms then reads one four byte word past the end for each such algorithm and, where the word read is zero, writes a fixed value over it. A peer offering many of them can corrupt heap metadata and abort the process. Only provider signature algorithms which occupy one of the excess slots, and which the server also has configured, have this effect. Codepoints the replacement context does not recognise are discarded without being resolved to a slot, and provider signature algorithms are usable only from TLS 1.3. The two contexts must therefore be aware of different numbers of provider signature algorithms, which requires separate library contexts, a provider loaded between the two being created, or providers which differ in what they advertise - in 4.0, for example, the default provider advertises SM2 where the FIPS provider does not. A deployment meeting the condition is also unable to negotiate the affected algorithms with legitimate clients, since the same stale count hides the corresponding certificates, so the misconfiguration is likely to be noticed. For that reason, and because the configuration is not the default, this issue has been assessed as Low severity. FIPS impact: no No FIPS modules are affected by this issue as the affected code is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75804", "url": "https://ubuntu.com/security/CVE-2026-75804", "cve_description": "Issue summary: OpenSSL QUIC stack does not enforce connection level flow control for streams. Remote peers may send more bytes as long as they fit within the stream flow control limits. Impact summary: A malicious remote peer may exploit the lack of connection flow control for streams to make the QUIC stack receive ~100MB of memory instead of 768 KiB (default flow control window size). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: The local QUIC stack advertises two flow control limits to its remote peer: stream flow control limit and connection flow control limit. The remote peer must follow both limits when transmitting stream data. Whenever the local QUIC stack receives a stream frame, it validates that the size of the received stream frame stays within flow control limits. If either limit is exceeded (stream level or connection level), then the QUIC stack must close the connection with a flow control error. The vulnerable OpenSSL QUIC stack enforces the stream-level but not the connection-level limit. To exploit the issue, three conditions must be met: - the remote peer opens several streams - each stream must stay within the stream-level flow control limit - there must be no zero-offset byte sent on any of the streams (to prevent the vulnerable QUIC stack from consuming data). By meeting the conditions above, the remote peer may make the local stack allocate 2 x MAX_STREAMS x (stream flow control limit) bytes of memory. MAX_STREAMS defaults to 100, and the limit applies to both bidirectional and unidirectional streams, making it 200 in total. The default flow control window for a stream is 512kB. The remote peer may force the vulnerable QUIC stack to allocate 100MB of heap per connection. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75805", "url": "https://ubuntu.com/security/CVE-2026-75805", "cve_description": "Issue summary: A CMP client that requests certificate revocation on the basis of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when processing a crafted revocation response. Impact summary: The NULL pointer dereference happens on a read which leads to a crash and a Denial of Service for the affected client application. CWE: CWE-476: NULL-pointer dereference Description: A CMP client revoking a certificate has to tell the server which certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the certificate itself or its issuer name and serial number. This is 'openssl cmp -cmd rr -csr ' on the command line, or OSSL_CMP_exec_RR_ses() with the certificate supplied via OSSL_CMP_CTX_set1_p10CSR() through the API. A CSR does not contain the issuer name and serial number of the certificate, so the client does not send them. A server may optionally name the certificate it revoked in its response, and the client then compares that name against what it sent. Having sent neither an issuer name nor a serial number, it has nothing to compare against, and a server returning a specially crafted name causes the client to read from a NULL pointer and crash. The revocation response is checked for valid message protection before the affected code is reached, so an attacker must be a malicious or compromised CMP server, or a man-in-the-middle in possession of the secret used for message protection. Clients that identify the certificate to be revoked by a certificate or by issuer and serial number rather than by a PKCS#10 CSR are not affected. FIPS impact: no No FIPS modules are affected by this issue, as the CMP protocol implementation is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75806", "url": "https://ubuntu.com/security/CVE-2026-75806", "cve_description": "Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-77696", "url": "https://ubuntu.com/security/CVE-2026-77696", "cve_description": "Issue summary: SM2 signature generation uses non-constant-time arithmetic on secret values, forming a timing side-channel. Impact summary: An attacker able to measure SM2 signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: SM2 signature generation computes the signature value using variable-time BIGNUM operations on the secret nonce and the private key, so the time taken to produce an SM2 signature depends on these secret values, forming a timing side-channel. Applications performing SM2 signature generation are affected on all platforms. FIPS Impact: no SM2 is not a FIPS algorithm.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84782", "url": "https://ubuntu.com/security/CVE-2026-84782", "cve_description": "Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "high", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84784", "url": "https://ubuntu.com/security/CVE-2026-84784", "cve_description": "Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use. Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired. The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame. Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth. [1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-42772", "url": "https://ubuntu.com/security/CVE-2026-42772", "cve_description": "Issue summary: The QUIC stream reassembly algorithm performance deteriorates progressively as packets are arriving out of order. The worst case has a quadratic complexity proportional to the number of stream frames kept in the buffer for the received stream data. Impact summary: A remote QUIC peer that completes the handshake can create a connection-scoped CPU pressure and potentially a Denial of Service using compliant STREAM frames inside the advertised receive window, with low attacker bandwidth. CWE: CWE-407: Inefficient Algorithmic Complexity Description: OpenSSL manages received QUIC stream fragments using a doubly-linked list. While it optimizes for append operations (at the end of the list), it falls back to a head-to-tail linear search for any fragment that does not immediately follow the current `tail`. By manipulating the sequence of offsets, an attacker can force the server to perform O(n^2) operations, consuming excessive CPU time for the QUIC process. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54873", "url": "https://ubuntu.com/security/CVE-2026-54873", "cve_description": "Issue summary: QUIC process may keep memory for QUIC packet buffer for much longer period than necessary. Impact summary: Remote peer can exploit this vulnerability by sending maliciously crafted packets, making the local QUIC stack to keep the memory for packet buffers allocated. The time for which the memory remains allocated is entirely under the control of the potentially malicious remote peer. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: To save copy operation from the packet buffer to the stream reassemble buffer the QUIC stack leaves the stream data on the packet buffer waiting to be copied to a buffer provided by the local receiving application. The QUIC stack releases a reference to the packet buffer only after the data are copied to the application buffer. This design is more efficient for legitimate data transfers but enables an attacker to allocate a lot more memory than actually required by the data kept in the receiving stream buffer. To mitigate the vulnerability, the QUIC stack now calculates and monitors memory overhead for every stream. The memory overhead for a single stream frame is calculated as a difference between the size of the whole packet that carries the stream frame and the size of the stream frame itself. The memory overhead for a single stream frame is added to the total (cumulative) memory overhead QUIC stack keeps for each stream. Once the cumulative memory overhead exceeds 64kB, the QUIC stack moves the stream frame data from the packet buffer to the stream buffer, starting with the next packet received. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Potential CPU DoS via O(n^2) Fragment Reassembly in QUIC", " - debian/patches/CVE-2026-42772-pre1.patch: Add a red-black tree", " implementation in crypto/build.info, crypto/rbtree/build.info,", " crypto/rbtree/rbtree.c, doc/internal/man7/ossl_rbtree.pod,", " include/internal/ossl_rbtree.h, ssl/build.info, test/build.info,", " test/ossl_rbtree_test.c, test/recipes/02-test_rbtree.t,", " util/missingcrypto-internal.txt.", " - debian/patches/CVE-2026-42772-pre2.patch: quic: move the RXE definition to", " a local header in ssl/quic/quic_record_rx.c,", " ssl/quic/quic_record_rx_local.h.", " - debian/patches/CVE-2026-42772-pre3.patch: test: cover the packet pinning", " path of QUIC stream reassembly in test/quic_stream_test.c.", " - debian/patches/CVE-2026-42772-pre4.patch: test: cover a long lagging read", " of packet backed stream data in test/quic_stream_test.c.", " - debian/patches/CVE-2026-42772-pre5.patch: test: reassemble small out of", " order frames and check the bytes in test/quic_stream_test.c.", " - debian/patches/CVE-2026-42772-pre6.patch: Add ossl_list_TYPE_join(head,", " tail) function in doc/internal/man3/DEFINE_LIST_OF.pod,", " include/internal/list.h, test/list_test.c.", " - debian/patches/CVE-2026-42772.patch: New implementation of stream", " reassembly for QUIC. in include/internal/quic_stream.h,", " include/internal/quic_strm_reas.h, ssl/quic/build.info,", " ssl/quic/quic_channel.c, ssl/quic/quic_rstream.c,", " ssl/quic/quic_strm_reas.c, test/quic_stream_test.c, test/quic_txp_test.c.", " - CVE-2026-42772", " * SECURITY UPDATE: QUIC STREAM Fragment Metadata DoS", " - debian/patches/CVE-2026-54873.patch: Limit packet buffer overhead to ~64kB", " per stream. in include/internal/quic_predef.h,", " include/internal/quic_stream.h, include/internal/quic_strm_reas.h,", " ssl/quic/quic_channel.c, ssl/quic/quic_channel_local.h,", " ssl/quic/quic_rstream.c, ssl/quic/quic_strm_reas.c,", " test/quic_stream_test.c, test/quic_txp_test.c.", " - debian/patches/CVE-2026-54873-post1.patch: Enforce final size for streams.", " in include/internal/quic_stream.h, ssl/quic/quic_channel.c,", " ssl/quic/quic_rstream.c, ssl/quic/quic_strm_reas.c,", " test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post2.patch: Add explicit tests to check", " some typical stream reassembly situation in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post3.patch: test: cover FIN final size", " against buffered data in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post4.patch: test: cover zero length read of", " a QUIC rstream in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post5.patch: test: cover two sided overlap", " of direct tail chunk in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post6.patch: test: cover cleansing of", " dropped duplicate bytes in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post7.patch: test: cover", " sc_data_trim_right() function in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post8.patch: make ch_cleanup() just safe", " enough to be called by quic_stream_test in ssl/quic/quic_channel.c.", " - CVE-2026-54873", "" ], "package": "openssl", "version": "3.5.5-1ubuntu3.7", "urgency": "medium", "distributions": "resolute-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 30 Sep 2026 14:46:30 -0400" }, { "cves": [ { "cve": "CVE-2026-35189", "url": "https://ubuntu.com/security/CVE-2026-35189", "cve_description": "Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-35191", "url": "https://ubuntu.com/security/CVE-2026-35191", "cve_description": "Issue summary: The OpenSSL QUIC server, when configured to not preform address validation, can be forced to count incoming packets multiple times in its unvalidated credit computation, leading to a violation of the RFC 9000 unvalidated connection amplification limit of 3 times the amount of data received. Impact summary: A remote attacker able to spoof packets to a server using the OpenSSL QUIC implementation might use the server for an amplification of a DDoS attack. CWE: CWE-440: Expected Behavior Violation Description: OpenSSL's QUIC stack, when operating as a server, enforces client address validation (RFC 9000, Section 8), to confirm the peer address is not used for a traffic amplification attack. If this feature is disabled on the server, the QUIC stack limits the amount of server data that can be sent to 3 times the amount of data received from the peer address, until such time as the TLS handshake is completed. The OpenSSL QUIC server, when operating in non-validation mode, adds the length of the whole datagram received to the unvalidated credit limit when processing each QUIC packet in the datagram. A remote peer may, after establishing a connection with an initial client hello frame, send a subsequent datagram containing multiple QUIC packets, leading the server to account the entire datagram length for each packet in the datagram, resulting in the server believing that the peer has sent more data than it actually has, thereby violating the 3x amplification limit mandated by the RFC. FIPS impact: no As the QUIC stack lives outside the FIPS module boundary, no FIPS modules are affected by this CVE.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54872", "url": "https://ubuntu.com/security/CVE-2026-54872", "cve_description": "Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature operations with curves that do not have a dedicated implementation leaks information about the secret nonce through timing. Impact summary: An attacker able to measure signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: The generic elliptic-curve scalar multiplication used for curves that do not have a dedicated constant-time implementation pads the secret scalar with non-constant-time BIGNUM operations, so the time taken depends on the value of the secret scalar derived from the ECDSA and SM2 nonce. The leak is very small; observing it requires a large number of measurements. The effect is largest for curves whose group order lies on a machine-word boundary, such as brainpoolP384r1. Applications using ECDSA signing over the Brainpool and other generic prime curves, and SM2 signing on platforms that use the generic implementation, are vulnerable to this issue. The NIST curves P-256, P-384 and P-521 use dedicated constant-time implementations and are not affected. FIPS Impact: no The FIPS modules are not affected: the approved NIST curves used in the FIPS provider have dedicated constant-time implementations and do not use the affected code path.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54875", "url": "https://ubuntu.com/security/CVE-2026-54875", "cve_description": "Issue summary: A non-constant-time optimized implementation of scalar point multiplication is used for SM2 private key operations on ARM64 and RISC-V platforms. Impact summary: An attacker able to measure the time taken by, or to observe the cache-line access pattern of SM2 signing or decryption on an affected platform can learn information about the secret scalar. CWE: CWE-208: Observable Timing Discrepancy Description: On ARM64 and RISC-V processors, the SM2 curve uses an optimized scalar multiplication implementation whose conditional branches and table look ups are chosen according to the bits of the secret scalar. The execution time and the cache-access pattern therefore depend on the long-term private key (during SM2 decryption) or the per-signature nonce (during SM2 signature generation), forming a timing and cache side-channel. FIPS Impact: no SM2 is not a FIPS algorithm and the optimized SM2 implementation is not part of the FIPS module. OpenSSL 4.0, 3.6, 3.5 and 3.4 are vulnerable to this issue on AArch64 and RISC-V. OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue. OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3. OpenSSL 3.6 users should upgrade to OpenSSL 3.6.5. OpenSSL 3.5 users should upgrade to OpenSSL 3.5.9. OpenSSL 3.4 users should upgrade to OpenSSL 3.4.8. This issue was reported on 2 May 2026 by Abhinav Agarwal. It was independently reported on 6 June 2026 by Feng Xue. The fix was developed by Igor Ustinov. -- cut (non-publishing metadata for internal use) -- Reported by: Abhinav Agarwal, Feng Xue Fixed by: Igor Ustinov", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-72897", "url": "https://ubuntu.com/security/CVE-2026-72897", "cve_description": "Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch a connection to a different SSL_CTX part way through a handshake may access memory beyond the end of an internal array if the replacement context knows about more provider signature algorithms than the context the connection was created from. Applications which never call SSL_set_SSL_CTX() are not affected. Impact summary: A remote peer may be able to cause a small out-of-bounds read, and in some circumstances a fixed-value out-of-bounds write, on the server heap. This may lead to a Denial of Service. CWE: CWE-787: Out-of-bounds Write Description: A TLS connection records how many certificate slots it has when it is created, taken from the SSL_CTX that created it: the built-in certificate types plus one slot for each provider TLS-SIGALG entry that context was aware of. That count sizes an internal array of per-slot certificate validity flags. An application may replace a connection's SSL_CTX part way through the handshake by calling SSL_set_SSL_CTX(), most commonly from a servername callback in order to serve a different virtual host. Doing so did not refresh the recorded count. A provider signature algorithm's slot index is its position in the list of whichever context resolves it, so if the replacement context is aware of more of them than the original, an algorithm offered by the peer can resolve to an index beyond the end of the array. Processing the peer's signature algorithms then reads one four byte word past the end for each such algorithm and, where the word read is zero, writes a fixed value over it. A peer offering many of them can corrupt heap metadata and abort the process. Only provider signature algorithms which occupy one of the excess slots, and which the server also has configured, have this effect. Codepoints the replacement context does not recognise are discarded without being resolved to a slot, and provider signature algorithms are usable only from TLS 1.3. The two contexts must therefore be aware of different numbers of provider signature algorithms, which requires separate library contexts, a provider loaded between the two being created, or providers which differ in what they advertise - in 4.0, for example, the default provider advertises SM2 where the FIPS provider does not. A deployment meeting the condition is also unable to negotiate the affected algorithms with legitimate clients, since the same stale count hides the corresponding certificates, so the misconfiguration is likely to be noticed. For that reason, and because the configuration is not the default, this issue has been assessed as Low severity. FIPS impact: no No FIPS modules are affected by this issue as the affected code is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75804", "url": "https://ubuntu.com/security/CVE-2026-75804", "cve_description": "Issue summary: OpenSSL QUIC stack does not enforce connection level flow control for streams. Remote peers may send more bytes as long as they fit within the stream flow control limits. Impact summary: A malicious remote peer may exploit the lack of connection flow control for streams to make the QUIC stack receive ~100MB of memory instead of 768 KiB (default flow control window size). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: The local QUIC stack advertises two flow control limits to its remote peer: stream flow control limit and connection flow control limit. The remote peer must follow both limits when transmitting stream data. Whenever the local QUIC stack receives a stream frame, it validates that the size of the received stream frame stays within flow control limits. If either limit is exceeded (stream level or connection level), then the QUIC stack must close the connection with a flow control error. The vulnerable OpenSSL QUIC stack enforces the stream-level but not the connection-level limit. To exploit the issue, three conditions must be met: - the remote peer opens several streams - each stream must stay within the stream-level flow control limit - there must be no zero-offset byte sent on any of the streams (to prevent the vulnerable QUIC stack from consuming data). By meeting the conditions above, the remote peer may make the local stack allocate 2 x MAX_STREAMS x (stream flow control limit) bytes of memory. MAX_STREAMS defaults to 100, and the limit applies to both bidirectional and unidirectional streams, making it 200 in total. The default flow control window for a stream is 512kB. The remote peer may force the vulnerable QUIC stack to allocate 100MB of heap per connection. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75805", "url": "https://ubuntu.com/security/CVE-2026-75805", "cve_description": "Issue summary: A CMP client that requests certificate revocation on the basis of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when processing a crafted revocation response. Impact summary: The NULL pointer dereference happens on a read which leads to a crash and a Denial of Service for the affected client application. CWE: CWE-476: NULL-pointer dereference Description: A CMP client revoking a certificate has to tell the server which certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the certificate itself or its issuer name and serial number. This is 'openssl cmp -cmd rr -csr ' on the command line, or OSSL_CMP_exec_RR_ses() with the certificate supplied via OSSL_CMP_CTX_set1_p10CSR() through the API. A CSR does not contain the issuer name and serial number of the certificate, so the client does not send them. A server may optionally name the certificate it revoked in its response, and the client then compares that name against what it sent. Having sent neither an issuer name nor a serial number, it has nothing to compare against, and a server returning a specially crafted name causes the client to read from a NULL pointer and crash. The revocation response is checked for valid message protection before the affected code is reached, so an attacker must be a malicious or compromised CMP server, or a man-in-the-middle in possession of the secret used for message protection. Clients that identify the certificate to be revoked by a certificate or by issuer and serial number rather than by a PKCS#10 CSR are not affected. FIPS impact: no No FIPS modules are affected by this issue, as the CMP protocol implementation is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75806", "url": "https://ubuntu.com/security/CVE-2026-75806", "cve_description": "Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-77696", "url": "https://ubuntu.com/security/CVE-2026-77696", "cve_description": "Issue summary: SM2 signature generation uses non-constant-time arithmetic on secret values, forming a timing side-channel. Impact summary: An attacker able to measure SM2 signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: SM2 signature generation computes the signature value using variable-time BIGNUM operations on the secret nonce and the private key, so the time taken to produce an SM2 signature depends on these secret values, forming a timing side-channel. Applications performing SM2 signature generation are affected on all platforms. FIPS Impact: no SM2 is not a FIPS algorithm.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84782", "url": "https://ubuntu.com/security/CVE-2026-84782", "cve_description": "Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "high", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84784", "url": "https://ubuntu.com/security/CVE-2026-84784", "cve_description": "Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use. Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired. The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame. Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth. [1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Excessive Memory Allocation in Relative CRLDP Processing", " - debian/patches/CVE-2026-35189.patch: Defer computation of relative CRLDP", " names in crypto/x509/v3_crld.c, crypto/x509/v3_purp.c,", " crypto/x509/x509_vfy.c, include/crypto/x509.h.", " - CVE-2026-35189", " * SECURITY UPDATE: QUIC Unvalidated Amplification Credit may be Over", " Accounted", " - debian/patches/CVE-2026-35191-01.patch: don't double count full databgram", " length on unvalidated connections in ssl/quic/quic_port.c,", " ssl/quic/quic_rx_depack.c.", " - debian/patches/CVE-2026-35191-02.patch: Add a test to check for quic", " unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-03.patch: fixup! don't double count full", " databgram length on unvalidated connections in ssl/quic/quic_rx_depack.c.", " - debian/patches/CVE-2026-35191-04.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-05.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-06.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-07.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-08.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-09.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-10.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - CVE-2026-35191", " * SECURITY UPDATE: Timing Side-Channel in Scalar Multiplication for Non-NIST", " EC Curves", " - debian/patches/CVE-2026-54872.patch: ec: make ossl_ec_scalar_mul_ladder()", " scalar padding constant time in crypto/bn/bn_intern.c,", " crypto/ec/ec_mult.c, include/crypto/bn.h.", " - CVE-2026-54872", " * SECURITY UPDATE: Non-Constant-Time SM2 Scalar Multiplication on ARM64 and", " RISC-V", " - debian/patches/CVE-2026-54875.patch: Make the ecp_sm2p256 scalar", " multiplication constant time in crypto/ec/ecp_sm2p256.c.", " - CVE-2026-54875", " * SECURITY UPDATE: Out-of-Bounds Access After SSL_set_SSL_CTX() During a", " Handshake", " - debian/patches/CVE-2026-72897-1.patch: Fix out-of-bounds valid_flags", " access after SSL_set_SSL_CTX() in ssl/ssl_lib.c.", " - debian/patches/CVE-2026-72897-2.patch: Add regression tests for the", " SSL_set_SSL_CTX() sigalg state in test/sslapitest.c.", " - debian/patches/CVE-2026-72897-3.patch: fixup! Fix out-of-bounds", " valid_flags access after SSL_set_SSL_CTX() in ssl/ssl_lib.c.", " - CVE-2026-72897", " * SECURITY UPDATE: QUIC Connection-Level Flow Control is Not Enforced for", " Streams", " - debian/patches/CVE-2026-75804-1.patch: CVE-2026-75804 QUIC connection-", " level flow control not enforced, remote memory exhaustion in", " ssl/quic/quic_fc.c.", " - debian/patches/CVE-2026-75804-2.patch: test verifies the connection level", " RX flow control window is enforced. in test/quic_fc_test.c.", " - CVE-2026-75804", " * SECURITY UPDATE: NULL Pointer Dereference in CMP Client Revocation Response", " Handling", " - debian/patches/CVE-2026-75805-1.patch: Guard comparison when values are", " NULL in crypto/cmp/cmp_client.c.", " - debian/patches/CVE-2026-75805-2.patch: Add test for CVE-2026-75805 in", " test/cmp_client_test.c.", " - CVE-2026-75805", " * SECURITY UPDATE: Unauthenticated and Undersized DTLS 1.2 AEAD Record Causes", " DoS", " - debian/patches/CVE-2026-75806.patch: TLS: Reject undersized TLS 1.2 AEAD", " records before AEAD processing in ssl/record/methods/tls1_meth.c,", " test/recordlentest.c.", " - CVE-2026-75806", " * SECURITY UPDATE: Timing Side-Channel in SM2 Signature Generation", " - debian/patches/CVE-2026-77696.patch: sm2: make sm2_sig_gen() constant time", " in crypto/ec/ec_mult.c, crypto/sm2/sm2_sign.c.", " - CVE-2026-77696", " * SECURITY UPDATE: DTLS Retransmits Handshake Messages From a Stale Buffer", " Offset", " - debian/patches/CVE-2026-84782.patch: dtls: reset init_off before", " retransmitting a message in ssl/d1_lib.c, ssl/statem/statem_dtls.c,", " test/dtlstest.c.", " - CVE-2026-84782", " * SECURITY UPDATE: QUIC: Unbounded RETIRE_CONNECTION_ID Backlog", " - debian/patches/CVE-2026-84784-1.patch: CVE-2026-84784 QUIC: unbounded", " RETIRE_CONNECTION_ID backlog (memory DoS) in ssl/quic/quic_channel.c.", " - debian/patches/CVE-2026-84784-2.patch: CVE-2026-84784 QUIC: unbounded", " RETIRE_CONNECTION_ID backlog (memory DoS) in test/radix/quic_ops.c,", " test/radix/quic_tests.c.", " - CVE-2026-84784", "" ], "package": "openssl", "version": "3.5.5-1ubuntu3.6", "urgency": "medium", "distributions": "resolute-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 16 Sep 2026 08:35:01 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "7.0.0-34.34", "version": "7.0.0-34.34" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "7.0.0-38.38", "version": "7.0.0-38.38" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Main version: 7.0.0-38.38", "" ], "package": "linux-meta", "version": "7.0.0-38.38", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [], "author": "Edoardo Canepa ", "date": "Fri, 04 Sep 2026 10:54:16 +0300" }, { "cves": [], "log": [ "", " * Main version: 7.0.0-37.37", "" ], "package": "linux-meta", "version": "7.0.0-37.37", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [], "author": "Edoardo Canepa ", "date": "Wed, 02 Sep 2026 13:54:21 +0300" }, { "cves": [], "log": [ "", " * Main version: 7.0.0-33.33", "" ], "package": "linux-meta", "version": "7.0.0-33.33", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [], "author": "Edoardo Canepa ", "date": "Sat, 29 Aug 2026 12:10:21 +0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssl", "from_version": { "source_package_name": "openssl", "source_package_version": "3.5.5-1ubuntu3.5", "version": "3.5.5-1ubuntu3.5" }, "to_version": { "source_package_name": "openssl", "source_package_version": "3.5.5-1ubuntu3.7", "version": "3.5.5-1ubuntu3.7" }, "cves": [ { "cve": "CVE-2026-42772", "url": "https://ubuntu.com/security/CVE-2026-42772", "cve_description": "Issue summary: The QUIC stream reassembly algorithm performance deteriorates progressively as packets are arriving out of order. The worst case has a quadratic complexity proportional to the number of stream frames kept in the buffer for the received stream data. Impact summary: A remote QUIC peer that completes the handshake can create a connection-scoped CPU pressure and potentially a Denial of Service using compliant STREAM frames inside the advertised receive window, with low attacker bandwidth. CWE: CWE-407: Inefficient Algorithmic Complexity Description: OpenSSL manages received QUIC stream fragments using a doubly-linked list. While it optimizes for append operations (at the end of the list), it falls back to a head-to-tail linear search for any fragment that does not immediately follow the current `tail`. By manipulating the sequence of offsets, an attacker can force the server to perform O(n^2) operations, consuming excessive CPU time for the QUIC process. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54873", "url": "https://ubuntu.com/security/CVE-2026-54873", "cve_description": "Issue summary: QUIC process may keep memory for QUIC packet buffer for much longer period than necessary. Impact summary: Remote peer can exploit this vulnerability by sending maliciously crafted packets, making the local QUIC stack to keep the memory for packet buffers allocated. The time for which the memory remains allocated is entirely under the control of the potentially malicious remote peer. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: To save copy operation from the packet buffer to the stream reassemble buffer the QUIC stack leaves the stream data on the packet buffer waiting to be copied to a buffer provided by the local receiving application. The QUIC stack releases a reference to the packet buffer only after the data are copied to the application buffer. This design is more efficient for legitimate data transfers but enables an attacker to allocate a lot more memory than actually required by the data kept in the receiving stream buffer. To mitigate the vulnerability, the QUIC stack now calculates and monitors memory overhead for every stream. The memory overhead for a single stream frame is calculated as a difference between the size of the whole packet that carries the stream frame and the size of the stream frame itself. The memory overhead for a single stream frame is added to the total (cumulative) memory overhead QUIC stack keeps for each stream. Once the cumulative memory overhead exceeds 64kB, the QUIC stack moves the stream frame data from the packet buffer to the stream buffer, starting with the next packet received. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-35189", "url": "https://ubuntu.com/security/CVE-2026-35189", "cve_description": "Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-35191", "url": "https://ubuntu.com/security/CVE-2026-35191", "cve_description": "Issue summary: The OpenSSL QUIC server, when configured to not preform address validation, can be forced to count incoming packets multiple times in its unvalidated credit computation, leading to a violation of the RFC 9000 unvalidated connection amplification limit of 3 times the amount of data received. Impact summary: A remote attacker able to spoof packets to a server using the OpenSSL QUIC implementation might use the server for an amplification of a DDoS attack. CWE: CWE-440: Expected Behavior Violation Description: OpenSSL's QUIC stack, when operating as a server, enforces client address validation (RFC 9000, Section 8), to confirm the peer address is not used for a traffic amplification attack. If this feature is disabled on the server, the QUIC stack limits the amount of server data that can be sent to 3 times the amount of data received from the peer address, until such time as the TLS handshake is completed. The OpenSSL QUIC server, when operating in non-validation mode, adds the length of the whole datagram received to the unvalidated credit limit when processing each QUIC packet in the datagram. A remote peer may, after establishing a connection with an initial client hello frame, send a subsequent datagram containing multiple QUIC packets, leading the server to account the entire datagram length for each packet in the datagram, resulting in the server believing that the peer has sent more data than it actually has, thereby violating the 3x amplification limit mandated by the RFC. FIPS impact: no As the QUIC stack lives outside the FIPS module boundary, no FIPS modules are affected by this CVE.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54872", "url": "https://ubuntu.com/security/CVE-2026-54872", "cve_description": "Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature operations with curves that do not have a dedicated implementation leaks information about the secret nonce through timing. Impact summary: An attacker able to measure signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: The generic elliptic-curve scalar multiplication used for curves that do not have a dedicated constant-time implementation pads the secret scalar with non-constant-time BIGNUM operations, so the time taken depends on the value of the secret scalar derived from the ECDSA and SM2 nonce. The leak is very small; observing it requires a large number of measurements. The effect is largest for curves whose group order lies on a machine-word boundary, such as brainpoolP384r1. Applications using ECDSA signing over the Brainpool and other generic prime curves, and SM2 signing on platforms that use the generic implementation, are vulnerable to this issue. The NIST curves P-256, P-384 and P-521 use dedicated constant-time implementations and are not affected. FIPS Impact: no The FIPS modules are not affected: the approved NIST curves used in the FIPS provider have dedicated constant-time implementations and do not use the affected code path.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54875", "url": "https://ubuntu.com/security/CVE-2026-54875", "cve_description": "Issue summary: A non-constant-time optimized implementation of scalar point multiplication is used for SM2 private key operations on ARM64 and RISC-V platforms. Impact summary: An attacker able to measure the time taken by, or to observe the cache-line access pattern of SM2 signing or decryption on an affected platform can learn information about the secret scalar. CWE: CWE-208: Observable Timing Discrepancy Description: On ARM64 and RISC-V processors, the SM2 curve uses an optimized scalar multiplication implementation whose conditional branches and table look ups are chosen according to the bits of the secret scalar. The execution time and the cache-access pattern therefore depend on the long-term private key (during SM2 decryption) or the per-signature nonce (during SM2 signature generation), forming a timing and cache side-channel. FIPS Impact: no SM2 is not a FIPS algorithm and the optimized SM2 implementation is not part of the FIPS module. OpenSSL 4.0, 3.6, 3.5 and 3.4 are vulnerable to this issue on AArch64 and RISC-V. OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue. OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3. OpenSSL 3.6 users should upgrade to OpenSSL 3.6.5. OpenSSL 3.5 users should upgrade to OpenSSL 3.5.9. OpenSSL 3.4 users should upgrade to OpenSSL 3.4.8. This issue was reported on 2 May 2026 by Abhinav Agarwal. It was independently reported on 6 June 2026 by Feng Xue. The fix was developed by Igor Ustinov. -- cut (non-publishing metadata for internal use) -- Reported by: Abhinav Agarwal, Feng Xue Fixed by: Igor Ustinov", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-72897", "url": "https://ubuntu.com/security/CVE-2026-72897", "cve_description": "Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch a connection to a different SSL_CTX part way through a handshake may access memory beyond the end of an internal array if the replacement context knows about more provider signature algorithms than the context the connection was created from. Applications which never call SSL_set_SSL_CTX() are not affected. Impact summary: A remote peer may be able to cause a small out-of-bounds read, and in some circumstances a fixed-value out-of-bounds write, on the server heap. This may lead to a Denial of Service. CWE: CWE-787: Out-of-bounds Write Description: A TLS connection records how many certificate slots it has when it is created, taken from the SSL_CTX that created it: the built-in certificate types plus one slot for each provider TLS-SIGALG entry that context was aware of. That count sizes an internal array of per-slot certificate validity flags. An application may replace a connection's SSL_CTX part way through the handshake by calling SSL_set_SSL_CTX(), most commonly from a servername callback in order to serve a different virtual host. Doing so did not refresh the recorded count. A provider signature algorithm's slot index is its position in the list of whichever context resolves it, so if the replacement context is aware of more of them than the original, an algorithm offered by the peer can resolve to an index beyond the end of the array. Processing the peer's signature algorithms then reads one four byte word past the end for each such algorithm and, where the word read is zero, writes a fixed value over it. A peer offering many of them can corrupt heap metadata and abort the process. Only provider signature algorithms which occupy one of the excess slots, and which the server also has configured, have this effect. Codepoints the replacement context does not recognise are discarded without being resolved to a slot, and provider signature algorithms are usable only from TLS 1.3. The two contexts must therefore be aware of different numbers of provider signature algorithms, which requires separate library contexts, a provider loaded between the two being created, or providers which differ in what they advertise - in 4.0, for example, the default provider advertises SM2 where the FIPS provider does not. A deployment meeting the condition is also unable to negotiate the affected algorithms with legitimate clients, since the same stale count hides the corresponding certificates, so the misconfiguration is likely to be noticed. For that reason, and because the configuration is not the default, this issue has been assessed as Low severity. FIPS impact: no No FIPS modules are affected by this issue as the affected code is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75804", "url": "https://ubuntu.com/security/CVE-2026-75804", "cve_description": "Issue summary: OpenSSL QUIC stack does not enforce connection level flow control for streams. Remote peers may send more bytes as long as they fit within the stream flow control limits. Impact summary: A malicious remote peer may exploit the lack of connection flow control for streams to make the QUIC stack receive ~100MB of memory instead of 768 KiB (default flow control window size). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: The local QUIC stack advertises two flow control limits to its remote peer: stream flow control limit and connection flow control limit. The remote peer must follow both limits when transmitting stream data. Whenever the local QUIC stack receives a stream frame, it validates that the size of the received stream frame stays within flow control limits. If either limit is exceeded (stream level or connection level), then the QUIC stack must close the connection with a flow control error. The vulnerable OpenSSL QUIC stack enforces the stream-level but not the connection-level limit. To exploit the issue, three conditions must be met: - the remote peer opens several streams - each stream must stay within the stream-level flow control limit - there must be no zero-offset byte sent on any of the streams (to prevent the vulnerable QUIC stack from consuming data). By meeting the conditions above, the remote peer may make the local stack allocate 2 x MAX_STREAMS x (stream flow control limit) bytes of memory. MAX_STREAMS defaults to 100, and the limit applies to both bidirectional and unidirectional streams, making it 200 in total. The default flow control window for a stream is 512kB. The remote peer may force the vulnerable QUIC stack to allocate 100MB of heap per connection. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75805", "url": "https://ubuntu.com/security/CVE-2026-75805", "cve_description": "Issue summary: A CMP client that requests certificate revocation on the basis of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when processing a crafted revocation response. Impact summary: The NULL pointer dereference happens on a read which leads to a crash and a Denial of Service for the affected client application. CWE: CWE-476: NULL-pointer dereference Description: A CMP client revoking a certificate has to tell the server which certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the certificate itself or its issuer name and serial number. This is 'openssl cmp -cmd rr -csr ' on the command line, or OSSL_CMP_exec_RR_ses() with the certificate supplied via OSSL_CMP_CTX_set1_p10CSR() through the API. A CSR does not contain the issuer name and serial number of the certificate, so the client does not send them. A server may optionally name the certificate it revoked in its response, and the client then compares that name against what it sent. Having sent neither an issuer name nor a serial number, it has nothing to compare against, and a server returning a specially crafted name causes the client to read from a NULL pointer and crash. The revocation response is checked for valid message protection before the affected code is reached, so an attacker must be a malicious or compromised CMP server, or a man-in-the-middle in possession of the secret used for message protection. Clients that identify the certificate to be revoked by a certificate or by issuer and serial number rather than by a PKCS#10 CSR are not affected. FIPS impact: no No FIPS modules are affected by this issue, as the CMP protocol implementation is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75806", "url": "https://ubuntu.com/security/CVE-2026-75806", "cve_description": "Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-77696", "url": "https://ubuntu.com/security/CVE-2026-77696", "cve_description": "Issue summary: SM2 signature generation uses non-constant-time arithmetic on secret values, forming a timing side-channel. Impact summary: An attacker able to measure SM2 signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: SM2 signature generation computes the signature value using variable-time BIGNUM operations on the secret nonce and the private key, so the time taken to produce an SM2 signature depends on these secret values, forming a timing side-channel. Applications performing SM2 signature generation are affected on all platforms. FIPS Impact: no SM2 is not a FIPS algorithm.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84782", "url": "https://ubuntu.com/security/CVE-2026-84782", "cve_description": "Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "high", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84784", "url": "https://ubuntu.com/security/CVE-2026-84784", "cve_description": "Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use. Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired. The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame. Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth. [1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-42772", "url": "https://ubuntu.com/security/CVE-2026-42772", "cve_description": "Issue summary: The QUIC stream reassembly algorithm performance deteriorates progressively as packets are arriving out of order. The worst case has a quadratic complexity proportional to the number of stream frames kept in the buffer for the received stream data. Impact summary: A remote QUIC peer that completes the handshake can create a connection-scoped CPU pressure and potentially a Denial of Service using compliant STREAM frames inside the advertised receive window, with low attacker bandwidth. CWE: CWE-407: Inefficient Algorithmic Complexity Description: OpenSSL manages received QUIC stream fragments using a doubly-linked list. While it optimizes for append operations (at the end of the list), it falls back to a head-to-tail linear search for any fragment that does not immediately follow the current `tail`. By manipulating the sequence of offsets, an attacker can force the server to perform O(n^2) operations, consuming excessive CPU time for the QUIC process. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54873", "url": "https://ubuntu.com/security/CVE-2026-54873", "cve_description": "Issue summary: QUIC process may keep memory for QUIC packet buffer for much longer period than necessary. Impact summary: Remote peer can exploit this vulnerability by sending maliciously crafted packets, making the local QUIC stack to keep the memory for packet buffers allocated. The time for which the memory remains allocated is entirely under the control of the potentially malicious remote peer. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: To save copy operation from the packet buffer to the stream reassemble buffer the QUIC stack leaves the stream data on the packet buffer waiting to be copied to a buffer provided by the local receiving application. The QUIC stack releases a reference to the packet buffer only after the data are copied to the application buffer. This design is more efficient for legitimate data transfers but enables an attacker to allocate a lot more memory than actually required by the data kept in the receiving stream buffer. To mitigate the vulnerability, the QUIC stack now calculates and monitors memory overhead for every stream. The memory overhead for a single stream frame is calculated as a difference between the size of the whole packet that carries the stream frame and the size of the stream frame itself. The memory overhead for a single stream frame is added to the total (cumulative) memory overhead QUIC stack keeps for each stream. Once the cumulative memory overhead exceeds 64kB, the QUIC stack moves the stream frame data from the packet buffer to the stream buffer, starting with the next packet received. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Potential CPU DoS via O(n^2) Fragment Reassembly in QUIC", " - debian/patches/CVE-2026-42772-pre1.patch: Add a red-black tree", " implementation in crypto/build.info, crypto/rbtree/build.info,", " crypto/rbtree/rbtree.c, doc/internal/man7/ossl_rbtree.pod,", " include/internal/ossl_rbtree.h, ssl/build.info, test/build.info,", " test/ossl_rbtree_test.c, test/recipes/02-test_rbtree.t,", " util/missingcrypto-internal.txt.", " - debian/patches/CVE-2026-42772-pre2.patch: quic: move the RXE definition to", " a local header in ssl/quic/quic_record_rx.c,", " ssl/quic/quic_record_rx_local.h.", " - debian/patches/CVE-2026-42772-pre3.patch: test: cover the packet pinning", " path of QUIC stream reassembly in test/quic_stream_test.c.", " - debian/patches/CVE-2026-42772-pre4.patch: test: cover a long lagging read", " of packet backed stream data in test/quic_stream_test.c.", " - debian/patches/CVE-2026-42772-pre5.patch: test: reassemble small out of", " order frames and check the bytes in test/quic_stream_test.c.", " - debian/patches/CVE-2026-42772-pre6.patch: Add ossl_list_TYPE_join(head,", " tail) function in doc/internal/man3/DEFINE_LIST_OF.pod,", " include/internal/list.h, test/list_test.c.", " - debian/patches/CVE-2026-42772.patch: New implementation of stream", " reassembly for QUIC. in include/internal/quic_stream.h,", " include/internal/quic_strm_reas.h, ssl/quic/build.info,", " ssl/quic/quic_channel.c, ssl/quic/quic_rstream.c,", " ssl/quic/quic_strm_reas.c, test/quic_stream_test.c, test/quic_txp_test.c.", " - CVE-2026-42772", " * SECURITY UPDATE: QUIC STREAM Fragment Metadata DoS", " - debian/patches/CVE-2026-54873.patch: Limit packet buffer overhead to ~64kB", " per stream. in include/internal/quic_predef.h,", " include/internal/quic_stream.h, include/internal/quic_strm_reas.h,", " ssl/quic/quic_channel.c, ssl/quic/quic_channel_local.h,", " ssl/quic/quic_rstream.c, ssl/quic/quic_strm_reas.c,", " test/quic_stream_test.c, test/quic_txp_test.c.", " - debian/patches/CVE-2026-54873-post1.patch: Enforce final size for streams.", " in include/internal/quic_stream.h, ssl/quic/quic_channel.c,", " ssl/quic/quic_rstream.c, ssl/quic/quic_strm_reas.c,", " test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post2.patch: Add explicit tests to check", " some typical stream reassembly situation in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post3.patch: test: cover FIN final size", " against buffered data in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post4.patch: test: cover zero length read of", " a QUIC rstream in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post5.patch: test: cover two sided overlap", " of direct tail chunk in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post6.patch: test: cover cleansing of", " dropped duplicate bytes in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post7.patch: test: cover", " sc_data_trim_right() function in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post8.patch: make ch_cleanup() just safe", " enough to be called by quic_stream_test in ssl/quic/quic_channel.c.", " - CVE-2026-54873", "" ], "package": "openssl", "version": "3.5.5-1ubuntu3.7", "urgency": "medium", "distributions": "resolute-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 30 Sep 2026 14:46:30 -0400" }, { "cves": [ { "cve": "CVE-2026-35189", "url": "https://ubuntu.com/security/CVE-2026-35189", "cve_description": "Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-35191", "url": "https://ubuntu.com/security/CVE-2026-35191", "cve_description": "Issue summary: The OpenSSL QUIC server, when configured to not preform address validation, can be forced to count incoming packets multiple times in its unvalidated credit computation, leading to a violation of the RFC 9000 unvalidated connection amplification limit of 3 times the amount of data received. Impact summary: A remote attacker able to spoof packets to a server using the OpenSSL QUIC implementation might use the server for an amplification of a DDoS attack. CWE: CWE-440: Expected Behavior Violation Description: OpenSSL's QUIC stack, when operating as a server, enforces client address validation (RFC 9000, Section 8), to confirm the peer address is not used for a traffic amplification attack. If this feature is disabled on the server, the QUIC stack limits the amount of server data that can be sent to 3 times the amount of data received from the peer address, until such time as the TLS handshake is completed. The OpenSSL QUIC server, when operating in non-validation mode, adds the length of the whole datagram received to the unvalidated credit limit when processing each QUIC packet in the datagram. A remote peer may, after establishing a connection with an initial client hello frame, send a subsequent datagram containing multiple QUIC packets, leading the server to account the entire datagram length for each packet in the datagram, resulting in the server believing that the peer has sent more data than it actually has, thereby violating the 3x amplification limit mandated by the RFC. FIPS impact: no As the QUIC stack lives outside the FIPS module boundary, no FIPS modules are affected by this CVE.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54872", "url": "https://ubuntu.com/security/CVE-2026-54872", "cve_description": "Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature operations with curves that do not have a dedicated implementation leaks information about the secret nonce through timing. Impact summary: An attacker able to measure signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: The generic elliptic-curve scalar multiplication used for curves that do not have a dedicated constant-time implementation pads the secret scalar with non-constant-time BIGNUM operations, so the time taken depends on the value of the secret scalar derived from the ECDSA and SM2 nonce. The leak is very small; observing it requires a large number of measurements. The effect is largest for curves whose group order lies on a machine-word boundary, such as brainpoolP384r1. Applications using ECDSA signing over the Brainpool and other generic prime curves, and SM2 signing on platforms that use the generic implementation, are vulnerable to this issue. The NIST curves P-256, P-384 and P-521 use dedicated constant-time implementations and are not affected. FIPS Impact: no The FIPS modules are not affected: the approved NIST curves used in the FIPS provider have dedicated constant-time implementations and do not use the affected code path.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54875", "url": "https://ubuntu.com/security/CVE-2026-54875", "cve_description": "Issue summary: A non-constant-time optimized implementation of scalar point multiplication is used for SM2 private key operations on ARM64 and RISC-V platforms. Impact summary: An attacker able to measure the time taken by, or to observe the cache-line access pattern of SM2 signing or decryption on an affected platform can learn information about the secret scalar. CWE: CWE-208: Observable Timing Discrepancy Description: On ARM64 and RISC-V processors, the SM2 curve uses an optimized scalar multiplication implementation whose conditional branches and table look ups are chosen according to the bits of the secret scalar. The execution time and the cache-access pattern therefore depend on the long-term private key (during SM2 decryption) or the per-signature nonce (during SM2 signature generation), forming a timing and cache side-channel. FIPS Impact: no SM2 is not a FIPS algorithm and the optimized SM2 implementation is not part of the FIPS module. OpenSSL 4.0, 3.6, 3.5 and 3.4 are vulnerable to this issue on AArch64 and RISC-V. OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue. OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3. OpenSSL 3.6 users should upgrade to OpenSSL 3.6.5. OpenSSL 3.5 users should upgrade to OpenSSL 3.5.9. OpenSSL 3.4 users should upgrade to OpenSSL 3.4.8. This issue was reported on 2 May 2026 by Abhinav Agarwal. It was independently reported on 6 June 2026 by Feng Xue. The fix was developed by Igor Ustinov. -- cut (non-publishing metadata for internal use) -- Reported by: Abhinav Agarwal, Feng Xue Fixed by: Igor Ustinov", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-72897", "url": "https://ubuntu.com/security/CVE-2026-72897", "cve_description": "Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch a connection to a different SSL_CTX part way through a handshake may access memory beyond the end of an internal array if the replacement context knows about more provider signature algorithms than the context the connection was created from. Applications which never call SSL_set_SSL_CTX() are not affected. Impact summary: A remote peer may be able to cause a small out-of-bounds read, and in some circumstances a fixed-value out-of-bounds write, on the server heap. This may lead to a Denial of Service. CWE: CWE-787: Out-of-bounds Write Description: A TLS connection records how many certificate slots it has when it is created, taken from the SSL_CTX that created it: the built-in certificate types plus one slot for each provider TLS-SIGALG entry that context was aware of. That count sizes an internal array of per-slot certificate validity flags. An application may replace a connection's SSL_CTX part way through the handshake by calling SSL_set_SSL_CTX(), most commonly from a servername callback in order to serve a different virtual host. Doing so did not refresh the recorded count. A provider signature algorithm's slot index is its position in the list of whichever context resolves it, so if the replacement context is aware of more of them than the original, an algorithm offered by the peer can resolve to an index beyond the end of the array. Processing the peer's signature algorithms then reads one four byte word past the end for each such algorithm and, where the word read is zero, writes a fixed value over it. A peer offering many of them can corrupt heap metadata and abort the process. Only provider signature algorithms which occupy one of the excess slots, and which the server also has configured, have this effect. Codepoints the replacement context does not recognise are discarded without being resolved to a slot, and provider signature algorithms are usable only from TLS 1.3. The two contexts must therefore be aware of different numbers of provider signature algorithms, which requires separate library contexts, a provider loaded between the two being created, or providers which differ in what they advertise - in 4.0, for example, the default provider advertises SM2 where the FIPS provider does not. A deployment meeting the condition is also unable to negotiate the affected algorithms with legitimate clients, since the same stale count hides the corresponding certificates, so the misconfiguration is likely to be noticed. For that reason, and because the configuration is not the default, this issue has been assessed as Low severity. FIPS impact: no No FIPS modules are affected by this issue as the affected code is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75804", "url": "https://ubuntu.com/security/CVE-2026-75804", "cve_description": "Issue summary: OpenSSL QUIC stack does not enforce connection level flow control for streams. Remote peers may send more bytes as long as they fit within the stream flow control limits. Impact summary: A malicious remote peer may exploit the lack of connection flow control for streams to make the QUIC stack receive ~100MB of memory instead of 768 KiB (default flow control window size). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: The local QUIC stack advertises two flow control limits to its remote peer: stream flow control limit and connection flow control limit. The remote peer must follow both limits when transmitting stream data. Whenever the local QUIC stack receives a stream frame, it validates that the size of the received stream frame stays within flow control limits. If either limit is exceeded (stream level or connection level), then the QUIC stack must close the connection with a flow control error. The vulnerable OpenSSL QUIC stack enforces the stream-level but not the connection-level limit. To exploit the issue, three conditions must be met: - the remote peer opens several streams - each stream must stay within the stream-level flow control limit - there must be no zero-offset byte sent on any of the streams (to prevent the vulnerable QUIC stack from consuming data). By meeting the conditions above, the remote peer may make the local stack allocate 2 x MAX_STREAMS x (stream flow control limit) bytes of memory. MAX_STREAMS defaults to 100, and the limit applies to both bidirectional and unidirectional streams, making it 200 in total. The default flow control window for a stream is 512kB. The remote peer may force the vulnerable QUIC stack to allocate 100MB of heap per connection. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75805", "url": "https://ubuntu.com/security/CVE-2026-75805", "cve_description": "Issue summary: A CMP client that requests certificate revocation on the basis of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when processing a crafted revocation response. Impact summary: The NULL pointer dereference happens on a read which leads to a crash and a Denial of Service for the affected client application. CWE: CWE-476: NULL-pointer dereference Description: A CMP client revoking a certificate has to tell the server which certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the certificate itself or its issuer name and serial number. This is 'openssl cmp -cmd rr -csr ' on the command line, or OSSL_CMP_exec_RR_ses() with the certificate supplied via OSSL_CMP_CTX_set1_p10CSR() through the API. A CSR does not contain the issuer name and serial number of the certificate, so the client does not send them. A server may optionally name the certificate it revoked in its response, and the client then compares that name against what it sent. Having sent neither an issuer name nor a serial number, it has nothing to compare against, and a server returning a specially crafted name causes the client to read from a NULL pointer and crash. The revocation response is checked for valid message protection before the affected code is reached, so an attacker must be a malicious or compromised CMP server, or a man-in-the-middle in possession of the secret used for message protection. Clients that identify the certificate to be revoked by a certificate or by issuer and serial number rather than by a PKCS#10 CSR are not affected. FIPS impact: no No FIPS modules are affected by this issue, as the CMP protocol implementation is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75806", "url": "https://ubuntu.com/security/CVE-2026-75806", "cve_description": "Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-77696", "url": "https://ubuntu.com/security/CVE-2026-77696", "cve_description": "Issue summary: SM2 signature generation uses non-constant-time arithmetic on secret values, forming a timing side-channel. Impact summary: An attacker able to measure SM2 signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: SM2 signature generation computes the signature value using variable-time BIGNUM operations on the secret nonce and the private key, so the time taken to produce an SM2 signature depends on these secret values, forming a timing side-channel. Applications performing SM2 signature generation are affected on all platforms. FIPS Impact: no SM2 is not a FIPS algorithm.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84782", "url": "https://ubuntu.com/security/CVE-2026-84782", "cve_description": "Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "high", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84784", "url": "https://ubuntu.com/security/CVE-2026-84784", "cve_description": "Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use. Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired. The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame. Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth. [1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Excessive Memory Allocation in Relative CRLDP Processing", " - debian/patches/CVE-2026-35189.patch: Defer computation of relative CRLDP", " names in crypto/x509/v3_crld.c, crypto/x509/v3_purp.c,", " crypto/x509/x509_vfy.c, include/crypto/x509.h.", " - CVE-2026-35189", " * SECURITY UPDATE: QUIC Unvalidated Amplification Credit may be Over", " Accounted", " - debian/patches/CVE-2026-35191-01.patch: don't double count full databgram", " length on unvalidated connections in ssl/quic/quic_port.c,", " ssl/quic/quic_rx_depack.c.", " - debian/patches/CVE-2026-35191-02.patch: Add a test to check for quic", " unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-03.patch: fixup! don't double count full", " databgram length on unvalidated connections in ssl/quic/quic_rx_depack.c.", " - debian/patches/CVE-2026-35191-04.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-05.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-06.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-07.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-08.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-09.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-10.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - CVE-2026-35191", " * SECURITY UPDATE: Timing Side-Channel in Scalar Multiplication for Non-NIST", " EC Curves", " - debian/patches/CVE-2026-54872.patch: ec: make ossl_ec_scalar_mul_ladder()", " scalar padding constant time in crypto/bn/bn_intern.c,", " crypto/ec/ec_mult.c, include/crypto/bn.h.", " - CVE-2026-54872", " * SECURITY UPDATE: Non-Constant-Time SM2 Scalar Multiplication on ARM64 and", " RISC-V", " - debian/patches/CVE-2026-54875.patch: Make the ecp_sm2p256 scalar", " multiplication constant time in crypto/ec/ecp_sm2p256.c.", " - CVE-2026-54875", " * SECURITY UPDATE: Out-of-Bounds Access After SSL_set_SSL_CTX() During a", " Handshake", " - debian/patches/CVE-2026-72897-1.patch: Fix out-of-bounds valid_flags", " access after SSL_set_SSL_CTX() in ssl/ssl_lib.c.", " - debian/patches/CVE-2026-72897-2.patch: Add regression tests for the", " SSL_set_SSL_CTX() sigalg state in test/sslapitest.c.", " - debian/patches/CVE-2026-72897-3.patch: fixup! Fix out-of-bounds", " valid_flags access after SSL_set_SSL_CTX() in ssl/ssl_lib.c.", " - CVE-2026-72897", " * SECURITY UPDATE: QUIC Connection-Level Flow Control is Not Enforced for", " Streams", " - debian/patches/CVE-2026-75804-1.patch: CVE-2026-75804 QUIC connection-", " level flow control not enforced, remote memory exhaustion in", " ssl/quic/quic_fc.c.", " - debian/patches/CVE-2026-75804-2.patch: test verifies the connection level", " RX flow control window is enforced. in test/quic_fc_test.c.", " - CVE-2026-75804", " * SECURITY UPDATE: NULL Pointer Dereference in CMP Client Revocation Response", " Handling", " - debian/patches/CVE-2026-75805-1.patch: Guard comparison when values are", " NULL in crypto/cmp/cmp_client.c.", " - debian/patches/CVE-2026-75805-2.patch: Add test for CVE-2026-75805 in", " test/cmp_client_test.c.", " - CVE-2026-75805", " * SECURITY UPDATE: Unauthenticated and Undersized DTLS 1.2 AEAD Record Causes", " DoS", " - debian/patches/CVE-2026-75806.patch: TLS: Reject undersized TLS 1.2 AEAD", " records before AEAD processing in ssl/record/methods/tls1_meth.c,", " test/recordlentest.c.", " - CVE-2026-75806", " * SECURITY UPDATE: Timing Side-Channel in SM2 Signature Generation", " - debian/patches/CVE-2026-77696.patch: sm2: make sm2_sig_gen() constant time", " in crypto/ec/ec_mult.c, crypto/sm2/sm2_sign.c.", " - CVE-2026-77696", " * SECURITY UPDATE: DTLS Retransmits Handshake Messages From a Stale Buffer", " Offset", " - debian/patches/CVE-2026-84782.patch: dtls: reset init_off before", " retransmitting a message in ssl/d1_lib.c, ssl/statem/statem_dtls.c,", " test/dtlstest.c.", " - CVE-2026-84782", " * SECURITY UPDATE: QUIC: Unbounded RETIRE_CONNECTION_ID Backlog", " - debian/patches/CVE-2026-84784-1.patch: CVE-2026-84784 QUIC: unbounded", " RETIRE_CONNECTION_ID backlog (memory DoS) in ssl/quic/quic_channel.c.", " - debian/patches/CVE-2026-84784-2.patch: CVE-2026-84784 QUIC: unbounded", " RETIRE_CONNECTION_ID backlog (memory DoS) in test/radix/quic_ops.c,", " test/radix/quic_tests.c.", " - CVE-2026-84784", "" ], "package": "openssl", "version": "3.5.5-1ubuntu3.6", "urgency": "medium", "distributions": "resolute-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 16 Sep 2026 08:35:01 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssl-provider-legacy", "from_version": { "source_package_name": "openssl", "source_package_version": "3.5.5-1ubuntu3.5", "version": "3.5.5-1ubuntu3.5" }, "to_version": { "source_package_name": "openssl", "source_package_version": "3.5.5-1ubuntu3.7", "version": "3.5.5-1ubuntu3.7" }, "cves": [ { "cve": "CVE-2026-42772", "url": "https://ubuntu.com/security/CVE-2026-42772", "cve_description": "Issue summary: The QUIC stream reassembly algorithm performance deteriorates progressively as packets are arriving out of order. The worst case has a quadratic complexity proportional to the number of stream frames kept in the buffer for the received stream data. Impact summary: A remote QUIC peer that completes the handshake can create a connection-scoped CPU pressure and potentially a Denial of Service using compliant STREAM frames inside the advertised receive window, with low attacker bandwidth. CWE: CWE-407: Inefficient Algorithmic Complexity Description: OpenSSL manages received QUIC stream fragments using a doubly-linked list. While it optimizes for append operations (at the end of the list), it falls back to a head-to-tail linear search for any fragment that does not immediately follow the current `tail`. By manipulating the sequence of offsets, an attacker can force the server to perform O(n^2) operations, consuming excessive CPU time for the QUIC process. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54873", "url": "https://ubuntu.com/security/CVE-2026-54873", "cve_description": "Issue summary: QUIC process may keep memory for QUIC packet buffer for much longer period than necessary. Impact summary: Remote peer can exploit this vulnerability by sending maliciously crafted packets, making the local QUIC stack to keep the memory for packet buffers allocated. The time for which the memory remains allocated is entirely under the control of the potentially malicious remote peer. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: To save copy operation from the packet buffer to the stream reassemble buffer the QUIC stack leaves the stream data on the packet buffer waiting to be copied to a buffer provided by the local receiving application. The QUIC stack releases a reference to the packet buffer only after the data are copied to the application buffer. This design is more efficient for legitimate data transfers but enables an attacker to allocate a lot more memory than actually required by the data kept in the receiving stream buffer. To mitigate the vulnerability, the QUIC stack now calculates and monitors memory overhead for every stream. The memory overhead for a single stream frame is calculated as a difference between the size of the whole packet that carries the stream frame and the size of the stream frame itself. The memory overhead for a single stream frame is added to the total (cumulative) memory overhead QUIC stack keeps for each stream. Once the cumulative memory overhead exceeds 64kB, the QUIC stack moves the stream frame data from the packet buffer to the stream buffer, starting with the next packet received. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-35189", "url": "https://ubuntu.com/security/CVE-2026-35189", "cve_description": "Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-35191", "url": "https://ubuntu.com/security/CVE-2026-35191", "cve_description": "Issue summary: The OpenSSL QUIC server, when configured to not preform address validation, can be forced to count incoming packets multiple times in its unvalidated credit computation, leading to a violation of the RFC 9000 unvalidated connection amplification limit of 3 times the amount of data received. Impact summary: A remote attacker able to spoof packets to a server using the OpenSSL QUIC implementation might use the server for an amplification of a DDoS attack. CWE: CWE-440: Expected Behavior Violation Description: OpenSSL's QUIC stack, when operating as a server, enforces client address validation (RFC 9000, Section 8), to confirm the peer address is not used for a traffic amplification attack. If this feature is disabled on the server, the QUIC stack limits the amount of server data that can be sent to 3 times the amount of data received from the peer address, until such time as the TLS handshake is completed. The OpenSSL QUIC server, when operating in non-validation mode, adds the length of the whole datagram received to the unvalidated credit limit when processing each QUIC packet in the datagram. A remote peer may, after establishing a connection with an initial client hello frame, send a subsequent datagram containing multiple QUIC packets, leading the server to account the entire datagram length for each packet in the datagram, resulting in the server believing that the peer has sent more data than it actually has, thereby violating the 3x amplification limit mandated by the RFC. FIPS impact: no As the QUIC stack lives outside the FIPS module boundary, no FIPS modules are affected by this CVE.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54872", "url": "https://ubuntu.com/security/CVE-2026-54872", "cve_description": "Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature operations with curves that do not have a dedicated implementation leaks information about the secret nonce through timing. Impact summary: An attacker able to measure signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: The generic elliptic-curve scalar multiplication used for curves that do not have a dedicated constant-time implementation pads the secret scalar with non-constant-time BIGNUM operations, so the time taken depends on the value of the secret scalar derived from the ECDSA and SM2 nonce. The leak is very small; observing it requires a large number of measurements. The effect is largest for curves whose group order lies on a machine-word boundary, such as brainpoolP384r1. Applications using ECDSA signing over the Brainpool and other generic prime curves, and SM2 signing on platforms that use the generic implementation, are vulnerable to this issue. The NIST curves P-256, P-384 and P-521 use dedicated constant-time implementations and are not affected. FIPS Impact: no The FIPS modules are not affected: the approved NIST curves used in the FIPS provider have dedicated constant-time implementations and do not use the affected code path.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54875", "url": "https://ubuntu.com/security/CVE-2026-54875", "cve_description": "Issue summary: A non-constant-time optimized implementation of scalar point multiplication is used for SM2 private key operations on ARM64 and RISC-V platforms. Impact summary: An attacker able to measure the time taken by, or to observe the cache-line access pattern of SM2 signing or decryption on an affected platform can learn information about the secret scalar. CWE: CWE-208: Observable Timing Discrepancy Description: On ARM64 and RISC-V processors, the SM2 curve uses an optimized scalar multiplication implementation whose conditional branches and table look ups are chosen according to the bits of the secret scalar. The execution time and the cache-access pattern therefore depend on the long-term private key (during SM2 decryption) or the per-signature nonce (during SM2 signature generation), forming a timing and cache side-channel. FIPS Impact: no SM2 is not a FIPS algorithm and the optimized SM2 implementation is not part of the FIPS module. OpenSSL 4.0, 3.6, 3.5 and 3.4 are vulnerable to this issue on AArch64 and RISC-V. OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue. OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3. OpenSSL 3.6 users should upgrade to OpenSSL 3.6.5. OpenSSL 3.5 users should upgrade to OpenSSL 3.5.9. OpenSSL 3.4 users should upgrade to OpenSSL 3.4.8. This issue was reported on 2 May 2026 by Abhinav Agarwal. It was independently reported on 6 June 2026 by Feng Xue. The fix was developed by Igor Ustinov. -- cut (non-publishing metadata for internal use) -- Reported by: Abhinav Agarwal, Feng Xue Fixed by: Igor Ustinov", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-72897", "url": "https://ubuntu.com/security/CVE-2026-72897", "cve_description": "Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch a connection to a different SSL_CTX part way through a handshake may access memory beyond the end of an internal array if the replacement context knows about more provider signature algorithms than the context the connection was created from. Applications which never call SSL_set_SSL_CTX() are not affected. Impact summary: A remote peer may be able to cause a small out-of-bounds read, and in some circumstances a fixed-value out-of-bounds write, on the server heap. This may lead to a Denial of Service. CWE: CWE-787: Out-of-bounds Write Description: A TLS connection records how many certificate slots it has when it is created, taken from the SSL_CTX that created it: the built-in certificate types plus one slot for each provider TLS-SIGALG entry that context was aware of. That count sizes an internal array of per-slot certificate validity flags. An application may replace a connection's SSL_CTX part way through the handshake by calling SSL_set_SSL_CTX(), most commonly from a servername callback in order to serve a different virtual host. Doing so did not refresh the recorded count. A provider signature algorithm's slot index is its position in the list of whichever context resolves it, so if the replacement context is aware of more of them than the original, an algorithm offered by the peer can resolve to an index beyond the end of the array. Processing the peer's signature algorithms then reads one four byte word past the end for each such algorithm and, where the word read is zero, writes a fixed value over it. A peer offering many of them can corrupt heap metadata and abort the process. Only provider signature algorithms which occupy one of the excess slots, and which the server also has configured, have this effect. Codepoints the replacement context does not recognise are discarded without being resolved to a slot, and provider signature algorithms are usable only from TLS 1.3. The two contexts must therefore be aware of different numbers of provider signature algorithms, which requires separate library contexts, a provider loaded between the two being created, or providers which differ in what they advertise - in 4.0, for example, the default provider advertises SM2 where the FIPS provider does not. A deployment meeting the condition is also unable to negotiate the affected algorithms with legitimate clients, since the same stale count hides the corresponding certificates, so the misconfiguration is likely to be noticed. For that reason, and because the configuration is not the default, this issue has been assessed as Low severity. FIPS impact: no No FIPS modules are affected by this issue as the affected code is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75804", "url": "https://ubuntu.com/security/CVE-2026-75804", "cve_description": "Issue summary: OpenSSL QUIC stack does not enforce connection level flow control for streams. Remote peers may send more bytes as long as they fit within the stream flow control limits. Impact summary: A malicious remote peer may exploit the lack of connection flow control for streams to make the QUIC stack receive ~100MB of memory instead of 768 KiB (default flow control window size). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: The local QUIC stack advertises two flow control limits to its remote peer: stream flow control limit and connection flow control limit. The remote peer must follow both limits when transmitting stream data. Whenever the local QUIC stack receives a stream frame, it validates that the size of the received stream frame stays within flow control limits. If either limit is exceeded (stream level or connection level), then the QUIC stack must close the connection with a flow control error. The vulnerable OpenSSL QUIC stack enforces the stream-level but not the connection-level limit. To exploit the issue, three conditions must be met: - the remote peer opens several streams - each stream must stay within the stream-level flow control limit - there must be no zero-offset byte sent on any of the streams (to prevent the vulnerable QUIC stack from consuming data). By meeting the conditions above, the remote peer may make the local stack allocate 2 x MAX_STREAMS x (stream flow control limit) bytes of memory. MAX_STREAMS defaults to 100, and the limit applies to both bidirectional and unidirectional streams, making it 200 in total. The default flow control window for a stream is 512kB. The remote peer may force the vulnerable QUIC stack to allocate 100MB of heap per connection. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75805", "url": "https://ubuntu.com/security/CVE-2026-75805", "cve_description": "Issue summary: A CMP client that requests certificate revocation on the basis of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when processing a crafted revocation response. Impact summary: The NULL pointer dereference happens on a read which leads to a crash and a Denial of Service for the affected client application. CWE: CWE-476: NULL-pointer dereference Description: A CMP client revoking a certificate has to tell the server which certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the certificate itself or its issuer name and serial number. This is 'openssl cmp -cmd rr -csr ' on the command line, or OSSL_CMP_exec_RR_ses() with the certificate supplied via OSSL_CMP_CTX_set1_p10CSR() through the API. A CSR does not contain the issuer name and serial number of the certificate, so the client does not send them. A server may optionally name the certificate it revoked in its response, and the client then compares that name against what it sent. Having sent neither an issuer name nor a serial number, it has nothing to compare against, and a server returning a specially crafted name causes the client to read from a NULL pointer and crash. The revocation response is checked for valid message protection before the affected code is reached, so an attacker must be a malicious or compromised CMP server, or a man-in-the-middle in possession of the secret used for message protection. Clients that identify the certificate to be revoked by a certificate or by issuer and serial number rather than by a PKCS#10 CSR are not affected. FIPS impact: no No FIPS modules are affected by this issue, as the CMP protocol implementation is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75806", "url": "https://ubuntu.com/security/CVE-2026-75806", "cve_description": "Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-77696", "url": "https://ubuntu.com/security/CVE-2026-77696", "cve_description": "Issue summary: SM2 signature generation uses non-constant-time arithmetic on secret values, forming a timing side-channel. Impact summary: An attacker able to measure SM2 signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: SM2 signature generation computes the signature value using variable-time BIGNUM operations on the secret nonce and the private key, so the time taken to produce an SM2 signature depends on these secret values, forming a timing side-channel. Applications performing SM2 signature generation are affected on all platforms. FIPS Impact: no SM2 is not a FIPS algorithm.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84782", "url": "https://ubuntu.com/security/CVE-2026-84782", "cve_description": "Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "high", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84784", "url": "https://ubuntu.com/security/CVE-2026-84784", "cve_description": "Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use. Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired. The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame. Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth. [1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-42772", "url": "https://ubuntu.com/security/CVE-2026-42772", "cve_description": "Issue summary: The QUIC stream reassembly algorithm performance deteriorates progressively as packets are arriving out of order. The worst case has a quadratic complexity proportional to the number of stream frames kept in the buffer for the received stream data. Impact summary: A remote QUIC peer that completes the handshake can create a connection-scoped CPU pressure and potentially a Denial of Service using compliant STREAM frames inside the advertised receive window, with low attacker bandwidth. CWE: CWE-407: Inefficient Algorithmic Complexity Description: OpenSSL manages received QUIC stream fragments using a doubly-linked list. While it optimizes for append operations (at the end of the list), it falls back to a head-to-tail linear search for any fragment that does not immediately follow the current `tail`. By manipulating the sequence of offsets, an attacker can force the server to perform O(n^2) operations, consuming excessive CPU time for the QUIC process. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54873", "url": "https://ubuntu.com/security/CVE-2026-54873", "cve_description": "Issue summary: QUIC process may keep memory for QUIC packet buffer for much longer period than necessary. Impact summary: Remote peer can exploit this vulnerability by sending maliciously crafted packets, making the local QUIC stack to keep the memory for packet buffers allocated. The time for which the memory remains allocated is entirely under the control of the potentially malicious remote peer. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: To save copy operation from the packet buffer to the stream reassemble buffer the QUIC stack leaves the stream data on the packet buffer waiting to be copied to a buffer provided by the local receiving application. The QUIC stack releases a reference to the packet buffer only after the data are copied to the application buffer. This design is more efficient for legitimate data transfers but enables an attacker to allocate a lot more memory than actually required by the data kept in the receiving stream buffer. To mitigate the vulnerability, the QUIC stack now calculates and monitors memory overhead for every stream. The memory overhead for a single stream frame is calculated as a difference between the size of the whole packet that carries the stream frame and the size of the stream frame itself. The memory overhead for a single stream frame is added to the total (cumulative) memory overhead QUIC stack keeps for each stream. Once the cumulative memory overhead exceeds 64kB, the QUIC stack moves the stream frame data from the packet buffer to the stream buffer, starting with the next packet received. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Potential CPU DoS via O(n^2) Fragment Reassembly in QUIC", " - debian/patches/CVE-2026-42772-pre1.patch: Add a red-black tree", " implementation in crypto/build.info, crypto/rbtree/build.info,", " crypto/rbtree/rbtree.c, doc/internal/man7/ossl_rbtree.pod,", " include/internal/ossl_rbtree.h, ssl/build.info, test/build.info,", " test/ossl_rbtree_test.c, test/recipes/02-test_rbtree.t,", " util/missingcrypto-internal.txt.", " - debian/patches/CVE-2026-42772-pre2.patch: quic: move the RXE definition to", " a local header in ssl/quic/quic_record_rx.c,", " ssl/quic/quic_record_rx_local.h.", " - debian/patches/CVE-2026-42772-pre3.patch: test: cover the packet pinning", " path of QUIC stream reassembly in test/quic_stream_test.c.", " - debian/patches/CVE-2026-42772-pre4.patch: test: cover a long lagging read", " of packet backed stream data in test/quic_stream_test.c.", " - debian/patches/CVE-2026-42772-pre5.patch: test: reassemble small out of", " order frames and check the bytes in test/quic_stream_test.c.", " - debian/patches/CVE-2026-42772-pre6.patch: Add ossl_list_TYPE_join(head,", " tail) function in doc/internal/man3/DEFINE_LIST_OF.pod,", " include/internal/list.h, test/list_test.c.", " - debian/patches/CVE-2026-42772.patch: New implementation of stream", " reassembly for QUIC. in include/internal/quic_stream.h,", " include/internal/quic_strm_reas.h, ssl/quic/build.info,", " ssl/quic/quic_channel.c, ssl/quic/quic_rstream.c,", " ssl/quic/quic_strm_reas.c, test/quic_stream_test.c, test/quic_txp_test.c.", " - CVE-2026-42772", " * SECURITY UPDATE: QUIC STREAM Fragment Metadata DoS", " - debian/patches/CVE-2026-54873.patch: Limit packet buffer overhead to ~64kB", " per stream. in include/internal/quic_predef.h,", " include/internal/quic_stream.h, include/internal/quic_strm_reas.h,", " ssl/quic/quic_channel.c, ssl/quic/quic_channel_local.h,", " ssl/quic/quic_rstream.c, ssl/quic/quic_strm_reas.c,", " test/quic_stream_test.c, test/quic_txp_test.c.", " - debian/patches/CVE-2026-54873-post1.patch: Enforce final size for streams.", " in include/internal/quic_stream.h, ssl/quic/quic_channel.c,", " ssl/quic/quic_rstream.c, ssl/quic/quic_strm_reas.c,", " test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post2.patch: Add explicit tests to check", " some typical stream reassembly situation in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post3.patch: test: cover FIN final size", " against buffered data in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post4.patch: test: cover zero length read of", " a QUIC rstream in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post5.patch: test: cover two sided overlap", " of direct tail chunk in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post6.patch: test: cover cleansing of", " dropped duplicate bytes in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post7.patch: test: cover", " sc_data_trim_right() function in test/quic_stream_test.c.", " - debian/patches/CVE-2026-54873-post8.patch: make ch_cleanup() just safe", " enough to be called by quic_stream_test in ssl/quic/quic_channel.c.", " - CVE-2026-54873", "" ], "package": "openssl", "version": "3.5.5-1ubuntu3.7", "urgency": "medium", "distributions": "resolute-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 30 Sep 2026 14:46:30 -0400" }, { "cves": [ { "cve": "CVE-2026-35189", "url": "https://ubuntu.com/security/CVE-2026-35189", "cve_description": "Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-35191", "url": "https://ubuntu.com/security/CVE-2026-35191", "cve_description": "Issue summary: The OpenSSL QUIC server, when configured to not preform address validation, can be forced to count incoming packets multiple times in its unvalidated credit computation, leading to a violation of the RFC 9000 unvalidated connection amplification limit of 3 times the amount of data received. Impact summary: A remote attacker able to spoof packets to a server using the OpenSSL QUIC implementation might use the server for an amplification of a DDoS attack. CWE: CWE-440: Expected Behavior Violation Description: OpenSSL's QUIC stack, when operating as a server, enforces client address validation (RFC 9000, Section 8), to confirm the peer address is not used for a traffic amplification attack. If this feature is disabled on the server, the QUIC stack limits the amount of server data that can be sent to 3 times the amount of data received from the peer address, until such time as the TLS handshake is completed. The OpenSSL QUIC server, when operating in non-validation mode, adds the length of the whole datagram received to the unvalidated credit limit when processing each QUIC packet in the datagram. A remote peer may, after establishing a connection with an initial client hello frame, send a subsequent datagram containing multiple QUIC packets, leading the server to account the entire datagram length for each packet in the datagram, resulting in the server believing that the peer has sent more data than it actually has, thereby violating the 3x amplification limit mandated by the RFC. FIPS impact: no As the QUIC stack lives outside the FIPS module boundary, no FIPS modules are affected by this CVE.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54872", "url": "https://ubuntu.com/security/CVE-2026-54872", "cve_description": "Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature operations with curves that do not have a dedicated implementation leaks information about the secret nonce through timing. Impact summary: An attacker able to measure signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: The generic elliptic-curve scalar multiplication used for curves that do not have a dedicated constant-time implementation pads the secret scalar with non-constant-time BIGNUM operations, so the time taken depends on the value of the secret scalar derived from the ECDSA and SM2 nonce. The leak is very small; observing it requires a large number of measurements. The effect is largest for curves whose group order lies on a machine-word boundary, such as brainpoolP384r1. Applications using ECDSA signing over the Brainpool and other generic prime curves, and SM2 signing on platforms that use the generic implementation, are vulnerable to this issue. The NIST curves P-256, P-384 and P-521 use dedicated constant-time implementations and are not affected. FIPS Impact: no The FIPS modules are not affected: the approved NIST curves used in the FIPS provider have dedicated constant-time implementations and do not use the affected code path.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54875", "url": "https://ubuntu.com/security/CVE-2026-54875", "cve_description": "Issue summary: A non-constant-time optimized implementation of scalar point multiplication is used for SM2 private key operations on ARM64 and RISC-V platforms. Impact summary: An attacker able to measure the time taken by, or to observe the cache-line access pattern of SM2 signing or decryption on an affected platform can learn information about the secret scalar. CWE: CWE-208: Observable Timing Discrepancy Description: On ARM64 and RISC-V processors, the SM2 curve uses an optimized scalar multiplication implementation whose conditional branches and table look ups are chosen according to the bits of the secret scalar. The execution time and the cache-access pattern therefore depend on the long-term private key (during SM2 decryption) or the per-signature nonce (during SM2 signature generation), forming a timing and cache side-channel. FIPS Impact: no SM2 is not a FIPS algorithm and the optimized SM2 implementation is not part of the FIPS module. OpenSSL 4.0, 3.6, 3.5 and 3.4 are vulnerable to this issue on AArch64 and RISC-V. OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue. OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3. OpenSSL 3.6 users should upgrade to OpenSSL 3.6.5. OpenSSL 3.5 users should upgrade to OpenSSL 3.5.9. OpenSSL 3.4 users should upgrade to OpenSSL 3.4.8. This issue was reported on 2 May 2026 by Abhinav Agarwal. It was independently reported on 6 June 2026 by Feng Xue. The fix was developed by Igor Ustinov. -- cut (non-publishing metadata for internal use) -- Reported by: Abhinav Agarwal, Feng Xue Fixed by: Igor Ustinov", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-72897", "url": "https://ubuntu.com/security/CVE-2026-72897", "cve_description": "Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch a connection to a different SSL_CTX part way through a handshake may access memory beyond the end of an internal array if the replacement context knows about more provider signature algorithms than the context the connection was created from. Applications which never call SSL_set_SSL_CTX() are not affected. Impact summary: A remote peer may be able to cause a small out-of-bounds read, and in some circumstances a fixed-value out-of-bounds write, on the server heap. This may lead to a Denial of Service. CWE: CWE-787: Out-of-bounds Write Description: A TLS connection records how many certificate slots it has when it is created, taken from the SSL_CTX that created it: the built-in certificate types plus one slot for each provider TLS-SIGALG entry that context was aware of. That count sizes an internal array of per-slot certificate validity flags. An application may replace a connection's SSL_CTX part way through the handshake by calling SSL_set_SSL_CTX(), most commonly from a servername callback in order to serve a different virtual host. Doing so did not refresh the recorded count. A provider signature algorithm's slot index is its position in the list of whichever context resolves it, so if the replacement context is aware of more of them than the original, an algorithm offered by the peer can resolve to an index beyond the end of the array. Processing the peer's signature algorithms then reads one four byte word past the end for each such algorithm and, where the word read is zero, writes a fixed value over it. A peer offering many of them can corrupt heap metadata and abort the process. Only provider signature algorithms which occupy one of the excess slots, and which the server also has configured, have this effect. Codepoints the replacement context does not recognise are discarded without being resolved to a slot, and provider signature algorithms are usable only from TLS 1.3. The two contexts must therefore be aware of different numbers of provider signature algorithms, which requires separate library contexts, a provider loaded between the two being created, or providers which differ in what they advertise - in 4.0, for example, the default provider advertises SM2 where the FIPS provider does not. A deployment meeting the condition is also unable to negotiate the affected algorithms with legitimate clients, since the same stale count hides the corresponding certificates, so the misconfiguration is likely to be noticed. For that reason, and because the configuration is not the default, this issue has been assessed as Low severity. FIPS impact: no No FIPS modules are affected by this issue as the affected code is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75804", "url": "https://ubuntu.com/security/CVE-2026-75804", "cve_description": "Issue summary: OpenSSL QUIC stack does not enforce connection level flow control for streams. Remote peers may send more bytes as long as they fit within the stream flow control limits. Impact summary: A malicious remote peer may exploit the lack of connection flow control for streams to make the QUIC stack receive ~100MB of memory instead of 768 KiB (default flow control window size). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: The local QUIC stack advertises two flow control limits to its remote peer: stream flow control limit and connection flow control limit. The remote peer must follow both limits when transmitting stream data. Whenever the local QUIC stack receives a stream frame, it validates that the size of the received stream frame stays within flow control limits. If either limit is exceeded (stream level or connection level), then the QUIC stack must close the connection with a flow control error. The vulnerable OpenSSL QUIC stack enforces the stream-level but not the connection-level limit. To exploit the issue, three conditions must be met: - the remote peer opens several streams - each stream must stay within the stream-level flow control limit - there must be no zero-offset byte sent on any of the streams (to prevent the vulnerable QUIC stack from consuming data). By meeting the conditions above, the remote peer may make the local stack allocate 2 x MAX_STREAMS x (stream flow control limit) bytes of memory. MAX_STREAMS defaults to 100, and the limit applies to both bidirectional and unidirectional streams, making it 200 in total. The default flow control window for a stream is 512kB. The remote peer may force the vulnerable QUIC stack to allocate 100MB of heap per connection. FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75805", "url": "https://ubuntu.com/security/CVE-2026-75805", "cve_description": "Issue summary: A CMP client that requests certificate revocation on the basis of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when processing a crafted revocation response. Impact summary: The NULL pointer dereference happens on a read which leads to a crash and a Denial of Service for the affected client application. CWE: CWE-476: NULL-pointer dereference Description: A CMP client revoking a certificate has to tell the server which certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the certificate itself or its issuer name and serial number. This is 'openssl cmp -cmd rr -csr ' on the command line, or OSSL_CMP_exec_RR_ses() with the certificate supplied via OSSL_CMP_CTX_set1_p10CSR() through the API. A CSR does not contain the issuer name and serial number of the certificate, so the client does not send them. A server may optionally name the certificate it revoked in its response, and the client then compares that name against what it sent. Having sent neither an issuer name nor a serial number, it has nothing to compare against, and a server returning a specially crafted name causes the client to read from a NULL pointer and crash. The revocation response is checked for valid message protection before the affected code is reached, so an attacker must be a malicious or compromised CMP server, or a man-in-the-middle in possession of the secret used for message protection. Clients that identify the certificate to be revoked by a certificate or by issuer and serial number rather than by a PKCS#10 CSR are not affected. FIPS impact: no No FIPS modules are affected by this issue, as the CMP protocol implementation is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75806", "url": "https://ubuntu.com/security/CVE-2026-75806", "cve_description": "Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-77696", "url": "https://ubuntu.com/security/CVE-2026-77696", "cve_description": "Issue summary: SM2 signature generation uses non-constant-time arithmetic on secret values, forming a timing side-channel. Impact summary: An attacker able to measure SM2 signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: SM2 signature generation computes the signature value using variable-time BIGNUM operations on the secret nonce and the private key, so the time taken to produce an SM2 signature depends on these secret values, forming a timing side-channel. Applications performing SM2 signature generation are affected on all platforms. FIPS Impact: no SM2 is not a FIPS algorithm.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84782", "url": "https://ubuntu.com/security/CVE-2026-84782", "cve_description": "Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "high", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84784", "url": "https://ubuntu.com/security/CVE-2026-84784", "cve_description": "Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use. Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired. The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the local stack receives an ACK for its RETIRE_CONNECTION_ID frame. Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth. [1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Excessive Memory Allocation in Relative CRLDP Processing", " - debian/patches/CVE-2026-35189.patch: Defer computation of relative CRLDP", " names in crypto/x509/v3_crld.c, crypto/x509/v3_purp.c,", " crypto/x509/x509_vfy.c, include/crypto/x509.h.", " - CVE-2026-35189", " * SECURITY UPDATE: QUIC Unvalidated Amplification Credit may be Over", " Accounted", " - debian/patches/CVE-2026-35191-01.patch: don't double count full databgram", " length on unvalidated connections in ssl/quic/quic_port.c,", " ssl/quic/quic_rx_depack.c.", " - debian/patches/CVE-2026-35191-02.patch: Add a test to check for quic", " unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-03.patch: fixup! don't double count full", " databgram length on unvalidated connections in ssl/quic/quic_rx_depack.c.", " - debian/patches/CVE-2026-35191-04.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-05.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-06.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-07.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-08.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-09.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - debian/patches/CVE-2026-35191-10.patch: fixup! Add a test to check for", " quic unvalidated credit in test/quicapitest.c.", " - CVE-2026-35191", " * SECURITY UPDATE: Timing Side-Channel in Scalar Multiplication for Non-NIST", " EC Curves", " - debian/patches/CVE-2026-54872.patch: ec: make ossl_ec_scalar_mul_ladder()", " scalar padding constant time in crypto/bn/bn_intern.c,", " crypto/ec/ec_mult.c, include/crypto/bn.h.", " - CVE-2026-54872", " * SECURITY UPDATE: Non-Constant-Time SM2 Scalar Multiplication on ARM64 and", " RISC-V", " - debian/patches/CVE-2026-54875.patch: Make the ecp_sm2p256 scalar", " multiplication constant time in crypto/ec/ecp_sm2p256.c.", " - CVE-2026-54875", " * SECURITY UPDATE: Out-of-Bounds Access After SSL_set_SSL_CTX() During a", " Handshake", " - debian/patches/CVE-2026-72897-1.patch: Fix out-of-bounds valid_flags", " access after SSL_set_SSL_CTX() in ssl/ssl_lib.c.", " - debian/patches/CVE-2026-72897-2.patch: Add regression tests for the", " SSL_set_SSL_CTX() sigalg state in test/sslapitest.c.", " - debian/patches/CVE-2026-72897-3.patch: fixup! Fix out-of-bounds", " valid_flags access after SSL_set_SSL_CTX() in ssl/ssl_lib.c.", " - CVE-2026-72897", " * SECURITY UPDATE: QUIC Connection-Level Flow Control is Not Enforced for", " Streams", " - debian/patches/CVE-2026-75804-1.patch: CVE-2026-75804 QUIC connection-", " level flow control not enforced, remote memory exhaustion in", " ssl/quic/quic_fc.c.", " - debian/patches/CVE-2026-75804-2.patch: test verifies the connection level", " RX flow control window is enforced. in test/quic_fc_test.c.", " - CVE-2026-75804", " * SECURITY UPDATE: NULL Pointer Dereference in CMP Client Revocation Response", " Handling", " - debian/patches/CVE-2026-75805-1.patch: Guard comparison when values are", " NULL in crypto/cmp/cmp_client.c.", " - debian/patches/CVE-2026-75805-2.patch: Add test for CVE-2026-75805 in", " test/cmp_client_test.c.", " - CVE-2026-75805", " * SECURITY UPDATE: Unauthenticated and Undersized DTLS 1.2 AEAD Record Causes", " DoS", " - debian/patches/CVE-2026-75806.patch: TLS: Reject undersized TLS 1.2 AEAD", " records before AEAD processing in ssl/record/methods/tls1_meth.c,", " test/recordlentest.c.", " - CVE-2026-75806", " * SECURITY UPDATE: Timing Side-Channel in SM2 Signature Generation", " - debian/patches/CVE-2026-77696.patch: sm2: make sm2_sig_gen() constant time", " in crypto/ec/ec_mult.c, crypto/sm2/sm2_sign.c.", " - CVE-2026-77696", " * SECURITY UPDATE: DTLS Retransmits Handshake Messages From a Stale Buffer", " Offset", " - debian/patches/CVE-2026-84782.patch: dtls: reset init_off before", " retransmitting a message in ssl/d1_lib.c, ssl/statem/statem_dtls.c,", " test/dtlstest.c.", " - CVE-2026-84782", " * SECURITY UPDATE: QUIC: Unbounded RETIRE_CONNECTION_ID Backlog", " - debian/patches/CVE-2026-84784-1.patch: CVE-2026-84784 QUIC: unbounded", " RETIRE_CONNECTION_ID backlog (memory DoS) in ssl/quic/quic_channel.c.", " - debian/patches/CVE-2026-84784-2.patch: CVE-2026-84784 QUIC: unbounded", " RETIRE_CONNECTION_ID backlog (memory DoS) in test/radix/quic_ops.c,", " test/radix/quic_tests.c.", " - CVE-2026-84784", "" ], "package": "openssl", "version": "3.5.5-1ubuntu3.6", "urgency": "medium", "distributions": "resolute-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 16 Sep 2026 08:35:01 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-jwt", "from_version": { "source_package_name": "pyjwt", "source_package_version": "2.10.1-4ubuntu1", "version": "2.10.1-4ubuntu1" }, "to_version": { "source_package_name": "pyjwt", "source_package_version": "2.10.1-4ubuntu1.1", "version": "2.10.1-4ubuntu1.1" }, "cves": [ { "cve": "CVE-2026-48522", "url": "https://ubuntu.com/security/CVE-2026-48522", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch. If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem), cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface), or forge tokens that PyJWT verifies as valid. The library does not directly return non-HTTP(S) URI contents to the attacker; the chained \"plant a JWKS to forge tokens\" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48523", "url": "https://ubuntu.com/security/CVE-2026-48523", "cve_description": "PyJWT is a JSON Web Token implementation in Python. From 2.9.0 to 2.12.1, there is a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.get_signing_key_from_jwt(...) flow. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48524", "url": "https://ubuntu.com/security/CVE-2026-48524", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient.get_signing_key() forces a fresh HTTP request to the JWKS endpoint for every JWT with an unknown kid value, with no rate limiting. Since kid comes from the unverified token header, an attacker can trigger unlimited outbound requests. The vulnerability surfaces only when a JWKS fetch fails; an attacker can attempt to provoke that with sustained unknown-kid traffic, but the outcome depends on upstream JWKS-endpoint behavior (rate limiting, transient errors) which is beyond the attacker's control. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48525", "url": "https://ubuntu.com/security/CVE-2026-48525", "cve_description": "PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option (\"b64\": false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48526", "url": "https://ubuntu.com/security/CVE-2026-48526", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-48522", "url": "https://ubuntu.com/security/CVE-2026-48522", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch. If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem), cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface), or forge tokens that PyJWT verifies as valid. The library does not directly return non-HTTP(S) URI contents to the attacker; the chained \"plant a JWKS to forge tokens\" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48523", "url": "https://ubuntu.com/security/CVE-2026-48523", "cve_description": "PyJWT is a JSON Web Token implementation in Python. From 2.9.0 to 2.12.1, there is a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.get_signing_key_from_jwt(...) flow. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48524", "url": "https://ubuntu.com/security/CVE-2026-48524", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient.get_signing_key() forces a fresh HTTP request to the JWKS endpoint for every JWT with an unknown kid value, with no rate limiting. Since kid comes from the unverified token header, an attacker can trigger unlimited outbound requests. The vulnerability surfaces only when a JWKS fetch fails; an attacker can attempt to provoke that with sustained unknown-kid traffic, but the outcome depends on upstream JWKS-endpoint behavior (rate limiting, transient errors) which is beyond the attacker's control. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48525", "url": "https://ubuntu.com/security/CVE-2026-48525", "cve_description": "PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option (\"b64\": false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48526", "url": "https://ubuntu.com/security/CVE-2026-48526", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: multiple security vulnerabilities", " - debian/patches/CVE-2026-48522-to-48526.patch: Bundle security fixes and", " hardening into 2.13.0 in jwt/algorithms.py, jwt/api_jws.py,", " jwt/jwks_client.py, tests/test_algorithms.py, tests/test_api_jws.py,", " tests/test_jwks_client.py.", " - CVE-2026-48522", " - CVE-2026-48523", " - CVE-2026-48524", " - CVE-2026-48525", " - CVE-2026-48526", "" ], "package": "pyjwt", "version": "2.10.1-4ubuntu1.1", "urgency": "medium", "distributions": "resolute-security", "launchpad_bugs_fixed": [], "author": "Shishir Subedi ", "date": "Mon, 21 Sep 2026 12:40:06 +0545" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-requests", "from_version": { "source_package_name": "requests", "source_package_version": "2.32.5+dfsg-1ubuntu1", "version": "2.32.5+dfsg-1ubuntu1" }, "to_version": { "source_package_name": "requests", "source_package_version": "2.32.5+dfsg-1ubuntu1.1", "version": "2.32.5+dfsg-1ubuntu1.1" }, "cves": [ { "cve": "CVE-2026-25645", "url": "https://ubuntu.com/security/CVE-2026-25645", "cve_description": "Requests is a HTTP library. Prior to version 2.33.0, the `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Standard usage of the Requests library is not affected by this vulnerability. Only applications that call `extract_zipped_paths()` directly are impacted. Starting in version 2.33.0, the library extracts files to a non-deterministic location. If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.", "cve_priority": "low", "cve_public_date": "2026-03-25 17:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-25645", "url": "https://ubuntu.com/security/CVE-2026-25645", "cve_description": "Requests is a HTTP library. Prior to version 2.33.0, the `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Standard usage of the Requests library is not affected by this vulnerability. Only applications that call `extract_zipped_paths()` directly are impacted. Starting in version 2.33.0, the library extracts files to a non-deterministic location. If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.", "cve_priority": "low", "cve_public_date": "2026-03-25 17:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Insecure Temporary File", " - debian/patches/CVE-2026-25645.patch: Extract to non-deterministic", " location", " - CVE-2026-25645", "" ], "package": "requests", "version": "2.32.5+dfsg-1ubuntu1.1", "urgency": "medium", "distributions": "resolute-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Wed, 23 Sep 2026 13:11:20 +1000" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-image-7.0.0-38-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "7.0.0-34.34", "version": null }, "to_version": { "source_package_name": "linux-signed", "source_package_version": "7.0.0-38.38", "version": "7.0.0-38.38" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 1786013, 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 7.0.0-38.38", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "7.0.0-38.38", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Fri, 04 Sep 2026 10:54:43 +0300" }, { "cves": [], "log": [ "", " * Main version: 7.0.0-37.37", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "7.0.0-37.37", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Wed, 02 Sep 2026 13:55:22 +0300" }, { "cves": [], "log": [ "", " * Main version: 7.0.0-33.33", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "7.0.0-33.33", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Sat, 29 Aug 2026 12:10:43 +0300" } ], "notes": "linux-image-7.0.0-38-generic version '7.0.0-38.38' (source package linux-signed version '7.0.0-38.38') was added. linux-image-7.0.0-38-generic version '7.0.0-38.38' has the same source package name, linux-signed, as removed package linux-image-7.0.0-34-generic. As such we can use the source package version of the removed package, '7.0.0-34.34', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-main-modules-zfs-7.0.0-38-generic", "from_version": { "source_package_name": "linux-main-signed", "source_package_version": "7.0.0-34.34", "version": null }, "to_version": { "source_package_name": "linux-main-signed", "source_package_version": "7.0.0-38.38", "version": "7.0.0-38.38" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 1786013, 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 7.0.0-34.34", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", " - [Packaging] debian/dkms-versions -- update from kernel-versions", " (main/s2026.08.03)", "" ], "package": "linux-main-signed", "version": "7.0.0-34.34", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Manuel Diewald ", "date": "Wed, 02 Sep 2026 11:38:23 +0200" }, { "cves": [], "log": [ "", " * Main version: 7.0.0-32.32", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-main-signed", "version": "7.0.0-32.32", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Manuel Diewald ", "date": "Fri, 28 Aug 2026 21:20:57 +0200" }, { "cves": [], "log": [ "", " * Main version: 7.0.0-31.31", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", " - [Packaging] debian/dkms-versions -- update from kernel-versions", " (main/2026.08.03)", "", " * Miscellaneous Ubuntu changes", " - [Packaging]: lmm: Add a symbol to use a local signed.tar.gz file", " - [Packaging]: lmm: Allow DKMS to be cross compiled", " - [Packaging]: lmm: Add a method to create unsigned packages", " - [Packaging]: lmm: Install DKMSs in ubuntu/dkms", " - [Packaging]: Update manifest file with new patches", "" ], "package": "linux-main-signed", "version": "7.0.0-31.31", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Sat, 01 Aug 2026 04:12:14 +0200" } ], "notes": "linux-main-modules-zfs-7.0.0-38-generic version '7.0.0-38.38' (source package linux-main-signed version '7.0.0-38.38') was added. linux-main-modules-zfs-7.0.0-38-generic version '7.0.0-38.38' has the same source package name, linux-main-signed, as removed package linux-main-modules-zfs-7.0.0-34-generic. As such we can use the source package version of the removed package, '7.0.0-34.34', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-modules-7.0.0-38-generic", "from_version": { "source_package_name": "linux", "source_package_version": "7.0.0-34.34", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "7.0.0-38.38", "version": "7.0.0-38.38" }, "cves": [ { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-68105", "url": "https://ubuntu.com/security/CVE-2026-68105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix kernel panic during driver load failure Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68109", "url": "https://ubuntu.com/security/CVE-2026-68109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68114", "url": "https://ubuntu.com/security/CVE-2026-68114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68431", "url": "https://ubuntu.com/security/CVE-2026-68431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68138", "url": "https://ubuntu.com/security/CVE-2026-68138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68082", "url": "https://ubuntu.com/security/CVE-2026-68082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-08 10:16:00 UTC" }, { "cve": "CVE-2026-68159", "url": "https://ubuntu.com/security/CVE-2026-68159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68163", "url": "https://ubuntu.com/security/CVE-2026-68163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_vma_mapped: fix device-private PMD handling Commit 65edfda6f3f2 (\"mm/rmap: extend rmap and migration support device-private entries\") introduced the concept of device-private PMD entries, but did not correctly update the rmap walk code to account for them. As a result, when page_vma_mapped_walk() encounters device-private PMD entries, it takes no action other than to acquire the PMD lock and exit. However this is highly problematic for two reasons - firstly, device private entries possess a PFN so check_pmd() needs to be called to ensure an overlapping PFN range. Secondly, and more importantly, if PVMW_MIGRATION is set the caller assumes the returned entry is a migration entry, resulting in memory corruption when the caller tries to interpret the device private entry as such. In addition, commit 146287290023 (\"mm/huge_memory: implement device-private THP splitting\") allowed device private PMDs to be split like THP mappings, but again did not update this code path. As a result, we might race a PMD split prior to acquiring the PMD lock. This patch addresses all of these issues by invoking check_pmd(), ensuring PMVW_MIGRATION is not set and checks whether a split raced us we do for PMD THP and migration entries. Instead of checking for a subset of the cases after taking the pmd_lock(), put device-private along with pmd_trans_huge() and pmd_is_migration_entry(). Also remove thp_migration_supported() as it is already guarded by pmd_is_migration_entry(). [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68166", "url": "https://ubuntu.com/security/CVE-2026-68166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68170", "url": "https://ubuntu.com/security/CVE-2026-68170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix stale skb->sk reference on subflow close The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68177", "url": "https://ubuntu.com/security/CVE-2026-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Delay module ref count for \"enable_event\" trigger Triggers are now delayed from freeing, but can still be triggered until after the RCU grace period has ended. The freeing of the enable_event data is put into the private_data_free() callback, but the put of the module refcount is done immediately. It is possible that if a module is removed that has an event that would enable (or disable) it is still active, it can read the data of the module after it is removed causing a use-after-free bug. Move the trace_event_put_ref() that releases the module into the delayed callback so that the module can not be removed until any reference to its events are finished.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68191", "url": "https://ubuntu.com/security/CVE-2026-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix NULL pointer dereference in rhash table destroy When unbinding the ath12k driver, kernel NULL pointer dereferences occur in irq_work_sync() called from rhashtable_destroy(). Two hash tables are affected: 1. ath12k_link_sta hash table in ath12k_base 2. ath12k_dp_link_peer hash table in ath12k_dp The issue happens because the destroy functions are called unconditionally in cleanup paths, but the hash tables are only initialized late in their respective init functions. If the device was never fully started or if the init functions failed before initializing the hash tables, the pointers will be NULL. The issues are always reproducible from a VM because the MSI addressing initialization is failing. Call trace for ath12k_link_sta_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k] ath12k_core_stop+0xe/0x80 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Call trace for ath12k_dp_link_peer_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k] ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Fix this by adding NULL checks before calling rhashtable_destroy() in both destroy functions. The NULL check approach was chosen because the rhashtable pointer serves as the initialization state indicator. The init can fail at various points, leaving some components uninitialized. Checking the pointer directly is simpler than adding separate state flags that would need synchronization.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64586", "url": "https://ubuntu.com/security/CVE-2026-64586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs \"reset\" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs \"reset\" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68208", "url": "https://ubuntu.com/security/CVE-2026-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: Fix the error code of devm_kzalloc() in vip_probe_slice() In vip_probe_slice(), the error check for devm_kzalloc() incorrectly uses PTR_ERR_OR_ZERO() which returns 0 for NULL pointer. Return -ENOMEM for devm_kzalloc() failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68224", "url": "https://ubuntu.com/security/CVE-2026-68224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mali-c55: Fix possible ERR_PTR in enable_streams The media_pad_remote_pad_unique() function returns either a valid pointer or an ERR_PTR() on failure (-ENOTUNIQ if multiple links are enabled, -ENOLINK if no connected pad is found). The return value was assigned directly to isp->remote_src and dereferenced in the next line without checking for errors, which could lead to an ERR_PTR dereference. Add proper error checking with IS_ERR() before dereferencing the pointer. Also set isp->remote_src to NULL on error to maintain consistency with other error paths in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68237", "url": "https://ubuntu.com/security/CVE-2026-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: fix indefinite fence wait during GPU reset pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue's fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68240", "url": "https://ubuntu.com/security/CVE-2026-68240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: publish dpagemap early to avoid device mapping leak on error drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68242", "url": "https://ubuntu.com/security/CVE-2026-68242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix NULL deref on sched_engine alloc failure Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68254", "url": "https://ubuntu.com/security/CVE-2026-68254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68436", "url": "https://ubuntu.com/security/CVE-2026-68436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use kvzalloc to allocate struct dc struct dc has grown large over time (most of it the two inlined dc_scratch_space copies) and now sits close to the page allocator's 4 MiB contiguous allocation limit. Its actual size is not fixed by the source alone, it also depends on the compiler and the .config, so it can easily cross 4 MiB, e.g. with a newer GCC or a config change. dc_create() allocates it with kzalloc(). Once struct dc exceeds 4 MiB the request is rounded up to order 11 (8 MiB), which is above MAX_PAGE_ORDER, so the page allocator warns and returns NULL. dc_create() then fails, DM init fails and amdgpu probe aborts with -EINVAL: WARNING: mm/page_alloc.c:5197 at __alloc_frozen_pages_noprof+0x2f9/0x380 dc_create+0x38/0x660 [amdgpu] amdgpu_dm_init+0x2d9/0x510 [amdgpu] dm_hw_init+0x1b/0x90 [amdgpu] amdgpu_device_init.cold+0x150d/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x19/0x80 [amdgpu] amdgpu_pci_probe+0x1e2/0x4c0 [amdgpu] dc_create() then returns NULL and DM init fails, which aborts the whole GPU init and makes amdgpu probe fail with -EINVAL (\"hw_init of IP block failed -22\"), leaving the display unusable. The subsequent amdgpu_irq_put() warnings during teardown are just fallout of unwinding a half-initialized device. struct dc is a software-only bookkeeping structure that is never handed to hardware DMA and is only ever kept as an opaque pointer, so it does not require physically contiguous memory. Allocate it with kvzalloc() (and free it with kvfree()) so that the allocator can fall back to vmalloc() when a contiguous allocation of that size is not available, which also avoids the MAX_PAGE_ORDER warning entirely. v2: - Rebase to amd-staging-drm-next. (cherry picked from commit 991e0516a8072f2292681c6ae98a924ab0e32575)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68447", "url": "https://ubuntu.com/security/CVE-2026-68447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3)", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68264", "url": "https://ubuntu.com/security/CVE-2026-68264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: Reset current_op in xe_pt_update_ops_init() xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org (cherry picked from commit 046045543e530605c441063535e7dca0075369a6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68265", "url": "https://ubuntu.com/security/CVE-2026-68265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68267", "url": "https://ubuntu.com/security/CVE-2026-68267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. (cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68273", "url": "https://ubuntu.com/security/CVE-2026-68273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68274", "url": "https://ubuntu.com/security/CVE-2026-68274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68283", "url": "https://ubuntu.com/security/CVE-2026-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free freeing trigger private data Commit 61d445af0a7c (\"tracing: Add bulk garbage collection of freeing event_trigger_data\") moved the kfree() of event_trigger_data to a kthread that runs tracepoint_synchronize_unregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from trigger_data_free(). event_hist_trigger_free(), event_hist_trigger_named_free() and event_enable_trigger_free() free their satellite data (hist_data, cmd_ops, enable_data) right after trigger_data_free() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the list_del_rcu()'d trigger, causing a use-after-free. The histogram teardown must stay synchronous: remove_hist_vars() and unregister_field_var_hists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correct barrier - tracepoint_synchronize_unregister(), matching the free kthread - before freeing. The enable trigger has no such synchronous requirement, and a blocking synchronize there would re-serialize the path that commit deliberately deferred. Give it an optional private_data_free() callback that the free kthread runs after its grace period, and free enable_data from there.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68286", "url": "https://ubuntu.com/security/CVE-2026-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68287", "url": "https://ubuntu.com/security/CVE-2026-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68288", "url": "https://ubuntu.com/security/CVE-2026-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68289", "url": "https://ubuntu.com/security/CVE-2026-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68291", "url": "https://ubuntu.com/security/CVE-2026-68291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68303", "url": "https://ubuntu.com/security/CVE-2026-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68312", "url": "https://ubuntu.com/security/CVE-2026-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing. The cifsFileInfo reference and the open server handle both leak. Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock. Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68316", "url": "https://ubuntu.com/security/CVE-2026-68316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Fix element size accounting for cmd stream validation There are 2 issues with the element size handling in the command stream validation which result in too small of a size calculated when the element size is 16/32/64 bits. For NHWC format, the element size is simply missing from the calculation. The bitfield for the element size is different between IFM/IFM2 and OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM uses bits 1:2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68440", "url": "https://ubuntu.com/security/CVE-2026-68440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix heap overflow when reading module EEPROM txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68323", "url": "https://ubuntu.com/security/CVE-2026-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68441", "url": "https://ubuntu.com/security/CVE-2026-68441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d (\"bpf: add bpf_redirect() helper\"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs. Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working. The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68337", "url": "https://ubuntu.com/security/CVE-2026-68337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject redirect helpers without a bpf_net_context The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \\ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68345", "url": "https://ubuntu.com/security/CVE-2026-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: guard MBWU state before adding it to garbage __destroy_component_cfg() adds each RIS mbwu_state object to the MPAM garbage list when destroying component configuration. However, mbwu_state is allocated per RIS and only for RISes with MBWU monitors. A component can therefore have comp->cfg allocated while some RISes still have ris->mbwu_state set to NULL. Passing a NULL mbwu_state to add_to_garbage() dereferences the NULL pointer inside the macro. Skip RISes that do not have an mbwu_state object before adding them to the garbage list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68347", "url": "https://ubuntu.com/security/CVE-2026-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68375", "url": "https://ubuntu.com/security/CVE-2026-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle partially initialized auxiliary devices bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68382", "url": "https://ubuntu.com/security/CVE-2026-68382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Hold device ref until queue teardown completes GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68383", "url": "https://ubuntu.com/security/CVE-2026-68383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Keep scheduler timeline name alive The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68390", "url": "https://ubuntu.com/security/CVE-2026-68390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups hci_conn_params_lookup requires hdev->lock be held, otherwise the list iteration or param access is not safe. Hold hdev->lock for params lookups in hci_sync.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68404", "url": "https://ubuntu.com/security/CVE-2026-68404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: use wiphy work for socket owner autodisconnect nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68367", "url": "https://ubuntu.com/security/CVE-2026-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68095", "url": "https://ubuntu.com/security/CVE-2026-68095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse-uring: fix race between registration and connection abortion This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls \"wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);\" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68173", "url": "https://ubuntu.com/security/CVE-2026-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: wait on ublk_dev_ready() instead of ub->completion ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an edge-triggered latch used as a proxy for the level condition \"every queue has fetched all I/O commands\", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68113", "url": "https://ubuntu.com/security/CVE-2026-68113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68118", "url": "https://ubuntu.com/security/CVE-2026-68118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68120", "url": "https://ubuntu.com/security/CVE-2026-68120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtase: Workaround for TX hang caused by hardware packet parsing The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68122", "url": "https://ubuntu.com/security/CVE-2026-68122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix peer refcount leak in TCP error paths When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window: CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68128", "url": "https://ubuntu.com/security/CVE-2026-68128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: reject out-of-range ptype in ice_parser_profile_init set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68132", "url": "https://ubuntu.com/security/CVE-2026-68132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68133", "url": "https://ubuntu.com/security/CVE-2026-68133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP Call Trace during PTP release If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68134", "url": "https://ubuntu.com/security/CVE-2026-68134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ptp_s390: Add missing facility check Only register the physical clock when facility 28 is installed and PTFF QAF returns that PTFF QPT is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68150", "url": "https://ubuntu.com/security/CVE-2026-68150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/super: fix emergency thaw double-unlock of s_umount do_thaw_all() iterates over all superblocks via __iterate_supers() with SUPER_ITER_EXCL, which acquires s_umount exclusively before calling the callback and releases it afterwards. However, the callback do_thaw_all_callback() calls thaw_super_locked() which unconditionally releases s_umount on every code path. This results in a second unlock attempt in __iterate_supers() that corrupts the rwsem state, triggering a DEBUG_RWSEMS warning: [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems [ 182.601865] ------------[ cut here ]------------ [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53 [ 182.604578] Modules linked in: [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy) [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 182.606417] Workqueue: events do_thaw_all [ 182.606750] RIP: 0010:up_write+0xaf/0x170 [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246 [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870 [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10 [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80 [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000 [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800 [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000 [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0 [ 182.613722] Call Trace: [ 182.613946] [ 182.614130] __iterate_supers+0x128/0x150 [ 182.614463] do_thaw_all+0x1b/0x30 [ 182.614759] process_scheduled_works+0xbb/0x3f0 [ 182.615150] ? __pfx_worker_thread+0x10/0x10 [ 182.615499] worker_thread+0x129/0x270 [ 182.615816] ? __pfx_worker_thread+0x10/0x10 [ 182.616201] kthread+0xe2/0x120 [ 182.616469] ? __pfx_kthread+0x10/0x10 [ 182.616792] ret_from_fork+0x15b/0x240 [ 182.617115] ? __pfx_kthread+0x10/0x10 [ 182.617426] ret_from_fork_asm+0x1a/0x30 [ 182.617761] [ 182.617968] ---[ end trace 0000000000000000 ]--- [ 182.618412] Emergency Thaw complete Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount in the callback via super_lock_excl() before calling thaw_super_locked(). This matches the locking pattern expected by thaw_super_locked() and eliminates the double unlock. While at it, remove the dead 'return;' at the end of do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68152", "url": "https://ubuntu.com/security/CVE-2026-68152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: fix use-after-free in AMT delayed works When an AMT device is removed, pending delayed works can still access the freed amt_dev structure, which may result in kernel crashes or memory corruption. amt_dev_stop() cancels req_wq and discovery_wq with cancel_delayed_work_sync(), but these works can be scheduled again from event_wq after the cancellation. This allows delayed works to access the freed amt_dev structure after the netdev has been released. The following is a simple race scenario: CPU0 CPU1 amt_dev_stop() cancel_delayed_work_sync() amt_event_work() mod_delayed_work(req_wq) free netdev req_wq accesses freed amt_dev Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and discovery_wq from being queued again and wait for running work items to complete. The delayed works are disabled after initialization in amt_newlink() and enabled only when the device is successfully opened. This keeps the delayed work lifecycle synchronized with the lifetime of the AMT device.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68168", "url": "https://ubuntu.com/security/CVE-2026-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix afs_edit_dir_remove() to get, not find, block 0 Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather than afs_dir_find_block() as the latter caches the found block in the afs_dir_iter and may[*] switch out the page it's on if another afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does. [*] There's more than one block per page.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68169", "url": "https://ubuntu.com/security/CVE-2026-68169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a \"not found\" sentinel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68172", "url": "https://ubuntu.com/security/CVE-2026-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: make huge_ptep_get handled unaligned addresses huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma). The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic. Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68174", "url": "https://ubuntu.com/security/CVE-2026-68174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix union collision of module and refcnt for dynamic events In 'struct trace_event_call', the 'module' pointer and the 'refcnt' atomic variable share the same memory space in a union. For dynamic events, the union member is 'refcnt', which acts as an active reference counter. When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or wprobe) has a non-zero reference count (e.g. due to active event triggers or perf attachments), its 'call->module' evaluates to a small non-zero integer instead of NULL. When filtering or setting events for a specific module (e.g., writing ':mod:' to 'set_event'), the code in '__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads 'call->module' directly without checking whether the event is dynamic. This causes the kernel to treat the small integer (refcnt) as a 'struct module' pointer, leading to a NULL/invalid pointer dereference (Oops) when dereferencing the module name. Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked before treating 'call->module' as a valid pointer in these code paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68434", "url": "https://ubuntu.com/security/CVE-2026-68434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms Commit b1b4efea05a5 (\"serial: 8250_mid: Disable DMA for selected platforms\") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68198", "url": "https://ubuntu.com/security/CVE-2026-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix use-after-free in aggr_reset_state() The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68200", "url": "https://ubuntu.com/security/CVE-2026-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: don't re-enter an instance callback that is still running The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68201", "url": "https://ubuntu.com/security/CVE-2026-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: drain a slave's callback before its master detaches it snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68211", "url": "https://ubuntu.com/security/CVE-2026-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32-dcmipp: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. dcmipp_bytecap_start_streaming() returned -EINVAL when the source subdevice could not be resolved from the media graph, before pm_runtime_resume_and_get() and media_pipeline_start() had been called. The remaining error paths already converge on the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate err_pm_put / err_media_pipeline_stop labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68230", "url": "https://ubuntu.com/security/CVE-2026-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: amlogic-c3: Add validations for ae and awb config Avoid invalid memory access if the zones_num is bigger than zone_weight. This patch fixes the following smatch errors: drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68232", "url": "https://ubuntu.com/security/CVE-2026-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68233", "url": "https://ubuntu.com/security/CVE-2026-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Shut down BO cache timer before teardown The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68238", "url": "https://ubuntu.com/security/CVE-2026-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68239", "url": "https://ubuntu.com/security/CVE-2026-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68241", "url": "https://ubuntu.com/security/CVE-2026-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/mst: limit DP MST ESI service loop The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68245", "url": "https://ubuntu.com/security/CVE-2026-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68252", "url": "https://ubuntu.com/security/CVE-2026-68252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68253", "url": "https://ubuntu.com/security/CVE-2026-68253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68257", "url": "https://ubuntu.com/security/CVE-2026-68257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68258", "url": "https://ubuntu.com/security/CVE-2026-68258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on CRIU restore queue type and mqd size We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68266", "url": "https://ubuntu.com/security/CVE-2026-68266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68268", "url": "https://ubuntu.com/security/CVE-2026-68268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Return error on non-migratable faults requiring devmem Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68270", "url": "https://ubuntu.com/security/CVE-2026-68270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Avoid possible truncation with calculating visible size Calculating the visible size of the system framebuffer can result in truncation of the result. The calculation uses 32-bit arithmetics, which can overflow if the values for height and stride are large. Fix the issue by multiplying with mul_u32_u32().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68275", "url": "https://ubuntu.com/security/CVE-2026-68275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68276", "url": "https://ubuntu.com/security/CVE-2026-68276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: fix cleaner shader IB buffer overflow The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68282", "url": "https://ubuntu.com/security/CVE-2026-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Add missing error check for platform_get_resource() Add missing error check for platform_get_resource() return value to prevent NULL pointer dereference when memory resource is not available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68292", "url": "https://ubuntu.com/security/CVE-2026-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68296", "url": "https://ubuntu.com/security/CVE-2026-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM Before commit 00d066a4d4ed (\"netdev_features: convert NETIF_F_LLTX to dev->lltx\"), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev->features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev->lltx flag, it placed 'dev->lltx = true' after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); Fix by moving dev->lltx = true before the early returns in both functions, restoring the original unconditional behavior.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64575", "url": "https://ubuntu.com/security/CVE-2026-64575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: fix double sock release on batch realloc bpf_iter_tcp_batch() releases the current batch via bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites each slot with the socket cookie, then grows the batch. cur_sk/end_sk are kept for bpf_iter_tcp_resume(), but on realloc failure the function returns ERR_PTR() before resume runs, leaving cur_sk < end_sk over slots that now hold cookies rather than sock pointers. bpf_iter_tcp_seq_stop() then calls bpf_iter_tcp_put_batch() again and dereferences a cookie as a struct sock. Empty the batch on the failure path so stop() does not release it again. The sockets were already freed by the first bpf_iter_tcp_put_batch(), so nothing leaks, and a later read() rescans the bucket from the start instead of skipping it. The sibling GFP_NOWAIT failure path still holds real socket references and is left for stop() to release. BUG: KASAN: null-ptr-deref in __sock_gen_cookie Read of size 8 at addr 0000000000000059 by task exploit ... __sock_gen_cookie (net/core/sock_diag.c:28) bpf_iter_tcp_put_batch (net/ipv4/tcp_ipv4.c:2918) bpf_iter_tcp_seq_stop (net/ipv4/tcp_ipv4.c:3270) bpf_seq_read (kernel/bpf/bpf_iter.c:205) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 entry_SYSCALL_64_after_hwframe Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68298", "url": "https://ubuntu.com/security/CVE-2026-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create() Commit 9e9787414882 (\"drm/xe/userptr: replace xe_hmm with gpusvm\") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a \"simple\" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68448", "url": "https://ubuntu.com/security/CVE-2026-68448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: check access to copy_file_range source with src mounter creds Commit 5dae222a5ff0c (\"vfs: allow copy_file_range to copy across devices\") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type. The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs. The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time. While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds. This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied. Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds. The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68307", "url": "https://ubuntu.com/security/CVE-2026-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix crash in reset link replay During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif->valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &vif->bss_conf for the legacy link.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68311", "url": "https://ubuntu.com/security/CVE-2026-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: guard link STA in decap offload mt7925_sta_set_decap_offload() iterates over the vif valid_links mask when updating decap offload state for an MLO station. The station may not have a link STA for every valid link of the vif, so mt792x_sta_to_link() can return NULL for a link that belongs to the vif but not to the station. The function currently dereferences mlink before checking whether the link WCID is ready. If mlink is NULL, setting or clearing MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer. Skip links without a station link before touching mlink->wcid.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68321", "url": "https://ubuntu.com/security/CVE-2026-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix FDIR filter leak on remove Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68330", "url": "https://ubuntu.com/security/CVE-2026-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix DMA direction for NPU mailbox buffer airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations. Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures dma_unmap_single() invalidates the CPU cache on non-coherent systems. The mailbox buffers are small so there is no performance concern.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68332", "url": "https://ubuntu.com/security/CVE-2026-68332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix potential use-after-free in airoha_ppe_deinit() airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 (\"net: airoha: Fix schedule while atomic in airoha_ppe_deinit()\") omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68334", "url": "https://ubuntu.com/security/CVE-2026-68334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68341", "url": "https://ubuntu.com/security/CVE-2026-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix use after free in unlock_ovpn() unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68342", "url": "https://ubuntu.com/security/CVE-2026-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: avoid putting unrelated P2P peer on socket release ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68356", "url": "https://ubuntu.com/security/CVE-2026-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: airoha: Prevent division by zero when clock frequency is zero clk_get_rate() can return 0 when the clock provider is not properly configured or the clock is unmanaged. The driver uses wdt_freq as a divisor directly in airoha_wdt_probe() to compute max_timeout and in airoha_wdt_get_timeleft() to compute the remaining time, which results in a division by zero. Add a check for wdt_freq == 0 in probe and return -EINVAL with dev_err_probe() to prevent the division by zero and provide a diagnostic message.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68358", "url": "https://ubuntu.com/security/CVE-2026-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-kraken3) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68374", "url": "https://ubuntu.com/security/CVE-2026-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: sysfs: add lock to bos_descriptors_read() Add a lock to the function bos_descriptors_read(). This function accesses udev->bos, which could be simultaneously freed in usb_reset_and_verify_device(), a function that is commonly called in drivers all over the kernel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68378", "url": "https://ubuntu.com/security/CVE-2026-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68379", "url": "https://ubuntu.com/security/CVE-2026-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TIME_WAIT socket reference leak on PSP policy failure Release the TIME_WAIT socket reference and jump to discard_it upon PSP policy failure in both IPv4 and IPv6 receive paths. This prevents a memory leak of tcp_tw_bucket structures.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68380", "url": "https://ubuntu.com/security/CVE-2026-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix use-after-free of mm_struct in job scheduler amdxdna_cmd_submit() stores current->mm in job->mm without holding any reference. aie2_sched_job_run() later access job->mm from the DRM scheduler worker thread. With only a raw pointer and no structural reference, the mm_struct can be freed before the scheduler runs the job. Fix this by calling mmgrab() to hold a structural mm_count reference for the lifetime of the job, paired with mmdrop() in every cleanup path.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68384", "url": "https://ubuntu.com/security/CVE-2026-68384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68385", "url": "https://ubuntu.com/security/CVE-2026-68385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/checksum: Fix csum_partial() without vector facility Currently csum_partial() calls csum_copy() with copy=false and dst=NULL. On machines without the vector facility, csum_copy() falls back to cksm(dst, ...), causing the checksum to be calculated from address zero instead of the source buffer. The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68387", "url": "https://ubuntu.com/security/CVE-2026-68387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: add locking for raw flags bitfield With commit 890e5198a6e5 (\"can: raw: use bitfields to store flags in struct raw_sock\") the formerly separate integer values have been integrated into a single bitfield. This led to a read-modify-write operation when changing a flag in raw_setsockopt() which now needs a locking to prevent concurrent access. Instead of adding a lock/unlock hell in each of the flag manipulations this patch introduces a wrapper for a new raw_setsockopt_locked() function analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c [mkl: use Closes tag instead of Link]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68393", "url": "https://ubuntu.com/security/CVE-2026-68393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: extend conn_hash lookup critical sections Using RCU-protected pointers outside the critical sections without refcount is incorrect and may result to UAF. Extend critical section to cover both hci_conn_hash lookup and use of the returned conn. Add surrounding rcu_read_lock() also when return value is not used, in preparation for RCU lockdep requirement to hci_lookup_le_connect(). This avoids concurrent deletion of the conn before we are done dereferencing it. Also, make sure to hold hdev->lock when accessing hdev->accept_list.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68394", "url": "https://ubuntu.com/security/CVE-2026-68394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter update changes an existing LE central connection. The queued work currently stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later LOAD_CONN_PARAM request can clear disabled parameters and free that entry before hci_cmd_sync_work() runs the queued callback. Do not keep the borrowed hci_conn_params pointer in queued work. Queue the hci_conn instead and hold a reference until the queued callback completes. When the work runs, revalidate that the connection is still present, look up the current hci_conn_params entry, and cancel the update if userspace removed that entry while the work was pending. Copy the interval values from the current params entry under hdev->lock, then drop the lock and keep using hci_le_conn_update_sync() to issue the update. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth] Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Allocated by task 466: hci_conn_params_add+0xa6/0x240 [bluetooth] load_conn_param+0x4e1/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Freed by task 474: kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth] load_conn_param+0x4bf/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68400", "url": "https://ubuntu.com/security/CVE-2026-68400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint memory access array and to comply with the FF-A spec instead of defaulting to `sizeof(struct ffa_mem_region)`. This requires moving `ffa_mem_region_additional_setup()` earlier in the setup flow. Also, add sanity checks to ensure the calculated descriptor offsets do not exceed `max_fragsize`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68401", "url": "https://ubuntu.com/security/CVE-2026-68401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() Sashiko (locally) reports multiple out-of-bound issues in ffa_setup_and_transmit: 1) Writing ep_mem_access->reserved can write out of bounds for FFA versions < 1.2 as ffa_emad_size_get() returns 16 bytes in that case while reserved has an offset of 24. Instead of zeroing fields, memset the struct to zero first based on the FFA version. 2) Make sure there is enough size to write constituents. While at it, convert the only sizeof() in the driver that uses a type instead of variable.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68409", "url": "https://ubuntu.com/security/CVE-2026-68409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: defer link RX stats percpu free to RCU sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU: \tsta_info_free_link(&alloc->info); \tkfree_rcu(alloc, rcu_head); The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists. The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU. Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68412", "url": "https://ubuntu.com/security/CVE-2026-68412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan() If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. Use the existing error handling path to fix it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64566", "url": "https://ubuntu.com/security/CVE-2026-64566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68415", "url": "https://ubuntu.com/security/CVE-2026-68415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear mode callbacks after failed mode setup xfrm_state_gc_task can run long after a failed IPTFS state setup. In the reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup returned -ENOMEM before publishing mode_data, and the temporary module reference from xfrm_get_mode_cbs() was dropped immediately. The dead state then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been unloaded. Clear x->mode_cbs when mode init or clone fails before publishing mode_data. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference. The buggy scenario involves two paths, with each column showing the order within that path: failed setup path: 1. cache x->mode_cbs 2. mode setup fails before mode_data 3. drop the temporary module ref 4. dead state keeps x->mode_cbs cached GC/unload path: 1. xfrm_state_put() queues GC work 2. xfrm_iptfs unloads later 3. xfrm_state_gc_task runs 4. GC dereferences stale x->mode_cbs This also covers the failed clone path where clone_state() returns before publishing mode_data. Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y failslab_stacktrace_filter matched xfrm_iptfs frames ack_error=-12 FAULT_INJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrm_state_gc_task RIP: xfrm_state_gc_task+0x142/0x650 Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs] Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68418", "url": "https://ubuntu.com/security/CVE-2026-68418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent user-triggered null deref on QP create Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp. While there was a check for iwqp->iwpbl != NULL, this check would only occur if req.user_wqe_bufs was non-zero. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref. Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68420", "url": "https://ubuntu.com/security/CVE-2026-68420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: reject optional IPTFS templates in outbound policies syzbot reported a stack-out-of-bounds read in xfrm_state_find() which flows from xfrm_tmpl_resolve_one(). Commit 3d776e31c841 (\"xfrm: Reject optional tunnel/BEET mode templates in outbound policies\") disallowed optional tunnel and BEET in outbound policies to prevent this. Later when IPTFS added, it was not covered by that fix and can still trigger the out-of-bounds read; Extend the check to disallow optional IPTFS in outbound policies as well. IPTFS should be identical to tunnel mode. IN and FWD policies are not affected: xfrm_tmpl_resolve_one() is only reachable via the outbound path. Reproducer, before: ip link add dummy0 type dummy ip link set dummy0 up ip addr add 10.1.1.1/24 dev dummy0 ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 mode transport ping -W 1 -c 1 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. [ 64.168420] ================================================================== [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844 [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full) [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 64.169977] Call Trace: [ 64.169977] [ 64.169977] dump_stack_lvl+0x47/0x70 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] print_report+0x152/0x4b0 [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0 [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __virt_addr_valid+0x21b/0x230 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] kasan_report+0xa8/0xd0 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm_dst_hash+0x24/0xc0 [ 64.169977] xfrm_state_find+0xa2d/0x2f90 [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570 [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10 [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 64.169977] ? kernel_text_address+0x5b/0x80 [ 64.169977] ? __kernel_text_address+0xe/0x30 [ 64.169977] ? unwind_get_return_address+0x5e/0x90 [ 64.169977] ? arch_stack_walk+0x8c/0xe0 [ 64.169977] xfrm_tmpl_resolve+0x130/0x200 [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10 [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110 [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10 [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310 [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80 [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10 [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110 [ 64.169977] ? kasan_save_track+0x10/0x30 [ 64.169977] xfrm_lookup_route+0x18/0xe0 [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530 [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 64.169977] ? do_raw_spin_lock+0x71/0xc0 [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 64.169977] release_sock+0xb0/0x170 [ 64.169977] udp_connect+0x43/0x50 [ 64.169977] __sys_connect+0xa6/0x100 [ 64.169977] ? alloc_fd+0x2e9/0x300 [ 64.169977] ? __pfx___sys_connect+0x10/0x10 [ 64.169977] ? preempt_latency ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68421", "url": "https://ubuntu.com/security/CVE-2026-68421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() put_prev_task_scx() warns when a runnable task drops to a lower sched_class without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have kept it running. Core scheduling breaks that: a forced-idle SMT sibling reschedules through the core_pick fast path in pick_next_task(), which skips pick_task_scx() and thus balance_one(), so a runnable task can drop to idle with ENQ_LAST unset. Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core scheduling forced the idle, while a match (or core scheduling off) still catches a genuine missing-ENQ_LAST drop.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68426", "url": "https://ubuntu.com/security/CVE-2026-68426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix stale skb->prev after async crypto steals a GSO segment skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev). When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free. Repoint skb->prev at the last retained segment before returning.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2023-20585", "url": "https://ubuntu.com/security/CVE-2023-20585", "cve_description": "Insufficient checks of the RMP on host buffer access in IOMMU may allow an attacker with privileges and a compromised hypervisor to trigger an out of bounds condition without RMP checks, resulting in a potential loss of confidential guest integrity.", "cve_priority": "low", "cve_public_date": "2026-04-16 19:16:00 UTC" }, { "cve": "CVE-2026-68364", "url": "https://ubuntu.com/security/CVE-2026-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72064", "url": "https://ubuntu.com/security/CVE-2026-72064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Sync page pool RX frags for CPU MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72098", "url": "https://ubuntu.com/security/CVE-2026-72098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: fix buffer overflow in FEC calculation There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) \tfio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72248", "url": "https://ubuntu.com/security/CVE-2026-72248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei .", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72249", "url": "https://ubuntu.com/security/CVE-2026-72249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72287", "url": "https://ubuntu.com/security/CVE-2026-72287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the \"normal\" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a \"late\" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72329", "url": "https://ubuntu.com/security/CVE-2026-72329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/liquidio: drop cached VF pci_dev LUT The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72355", "url": "https://ubuntu.com/security/CVE-2026-72355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix barriering when walking subrequest list Fix the barriering used when walking the subrequest list in retry as there's a possibility of seeing a subreq that's just been added by the application thread.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72412", "url": "https://ubuntu.com/security/CVE-2026-72412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix handling of _PAGE_UNUSED pte bit The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72417", "url": "https://ubuntu.com/security/CVE-2026-72417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72442", "url": "https://ubuntu.com/security/CVE-2026-72442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix and simplify IP6IP6 tunnel handling Fix nf_flow_ip6_tunnel_proto() to use pskb_may_pull() instead of skb_header_pointer() to ensure the outer IPv6 header is in the skb headroom, which is required for subsequent packet processing. Move ctx->offset update inside the IPPROTO_IPV6 conditional block since it should only be adjusted when an IP6IP6 tunnel is actually detected. Simplify the rx path by removing ipv6_skip_exthdr() and checking ip6h->nexthdr directly, as the flowtable fast path only handles simple IP6IP6 encapsulation without extension headers. Drop the tunnel encapsulation limit destination option support from the tx path to match, since the rx path no longer handles extension headers. Remove the encap_limit parameter from nf_flow_offload_ipv6_forward(), nf_flow_tunnel_ip6ip6_push() and nf_flow_tunnel_v6_push(), along with the ipv6_tel_txoption struct and related headroom/MTU adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72463", "url": "https://ubuntu.com/security/CVE-2026-72463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix dev use-after-free in xfrm async resumption xfrm async resumption hold skb->dev refcnt until after transport_finish. However, xfrm_rcv_cb may modify skb->dev to tunnel dev without taking device reference, such as vti_rcv_cb. The subsequent async resumption will decrement the tunnel device's reference count, which lead to uaf of tunnel dev and refcnt leak of orig dev as below: unregister_netdevice: waiting for vti1 to become free. Usage count = -2 Stash the original skb->dev to fix refcnt imbalance. The new skb->dev set by xfrm_rcv_cb can race with device teardown. Extend rcu protection over xfrm_rcv_cb and transport_finish to prevent races.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72477", "url": "https://ubuntu.com/security/CVE-2026-72477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: call _ntfs_bad_inode() when failing to rename It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce (\"fs/ntfs3: Exclude call make_bad_inode for live nodes.\") The WARN_ON was added when it wasn't safe by: commit d99208b91933 (\"fs/ntfs3: cancle set bad inode after removing name fails\") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72493", "url": "https://ubuntu.com/security/CVE-2026-72493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: serialize netif_running() check in enqueue_to_backlog() Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 (\"net: do not process device backlog during unregistration\") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72494", "url": "https://ubuntu.com/security/CVE-2026-72494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Replace waitqueue and flag with completion The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72496", "url": "https://ubuntu.com/security/CVE-2026-72496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74269", "url": "https://ubuntu.com/security/CVE-2026-74269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt: fix head underflow on XDP head-grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74350", "url": "https://ubuntu.com/security/CVE-2026-74350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate fast symlink target during inode read ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72495", "url": "https://ubuntu.com/security/CVE-2026-72495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72501", "url": "https://ubuntu.com/security/CVE-2026-72501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Initialize dpi variable to zero dpi is initialized only for BNXT_RE_ALLOC_WC_PAGE, but copied for all the cases. So initialize the dpi to 0.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72278", "url": "https://ubuntu.com/security/CVE-2026-72278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68083", "url": "https://ubuntu.com/security/CVE-2026-68083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix path resolution in ksmbd_vfs_kern_path_create The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an absolute path with convert_to_unix_name() and resolves it from AT_FDCWD via start_creating_path(), so a \"..\" component is walked from the real filesystem root and escapes the export. An authenticated client races a missing path component so the rooted open lookup returns -ENOENT (taking the create branch) while the same component is present (a directory) when the create walk runs; the create then resolves \"..\" out of the share. Root the create walk at the share like the lookup and rename paths already are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH, &share_conf->vfs_path) and create the final component with start_creating_noperm(). convert_to_unix_name() then has no callers and is removed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-68457", "url": "https://ubuntu.com/security/CVE-2026-68457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for FSCTL mutations SET_SPARSE, SET_ZERO_DATA and SET_COMPRESSION operate on an open SMB handle but call VFS xattr, fallocate or fileattr helpers with the current ksmbd worker credentials. Those helpers can revalidate inode permissions, ownership and LSM policy independently of the SMB handle access mask. Run each operation with the credentials captured in the target file when the handle was opened. Keep credential handling local to these single-file FSCTLs rather than applying session credentials to the complete IOCTL handler, which also contains handle-less and multi-handle operations.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72041", "url": "https://ubuntu.com/security/CVE-2026-72041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: use sk_msg_free_partial to fix partial send sk_msg_free_partial() ensures consistency of the skmsg at every iteration, without having to manually handle uncharges and offsets. This simplifies the code, and fixes some bugs in skmsg accounting when we don't send the full contents.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72046", "url": "https://ubuntu.com/security/CVE-2026-72046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72137", "url": "https://ubuntu.com/security/CVE-2026-72137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: nat_keepalive: avoid double free on send error nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72139", "url": "https://ubuntu.com/security/CVE-2026-72139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: \tif (needs_md5) { \t\ttcp_ao_destroy_sock(sk, false); \t} else if (needs_ao) { \t\ttcp_clear_md5_list(sk); \t\tkfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); \t} Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72191", "url": "https://ubuntu.com/security/CVE-2026-72191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: validate split-point offset in indx_insert_into_buffer indx_insert_into_buffer() computes used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off)); where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes. A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel. Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount). Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns. A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e (\"fs/ntfs3: Fix OOB read in indx_insert_into_buffer\") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72217", "url": "https://ubuntu.com/security/CVE-2026-72217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it. rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes. Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72220", "url": "https://ubuntu.com/security/CVE-2026-72220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72221", "url": "https://ubuntu.com/security/CVE-2026-72221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72222", "url": "https://ubuntu.com/security/CVE-2026-72222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: pin svc_xprt across the asynchronous TLS handshake callback svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of(). Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done. The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry. Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all(). [cel: rewrote commit message to describe the actual change]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72277", "url": "https://ubuntu.com/security/CVE-2026-72277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72279", "url": "https://ubuntu.com/security/CVE-2026-72279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint. Conveniently, this also plugs a page leak found by Sashiko [*] resulting from the early return for a read-only PFN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72288", "url": "https://ubuntu.com/security/CVE-2026-72288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72317", "url": "https://ubuntu.com/security/CVE-2026-72317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: pin upper rpc_clnt across the TLS connect_worker The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72318", "url": "https://ubuntu.com/security/CVE-2026-72318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate DFS referral string offsets parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server. Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds. Validate each string offset before deriving the string pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72320", "url": "https://ubuntu.com/security/CVE-2026-72320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_lookup: fix catchall element handling with inverted lookups nft_lookup_eval() decides whether a lookup matched (`found`) from the direct set lookup and priv->invert before falling back to the catchall element used by interval sets (e.g. nft_set_rbtree) for the open-ended default range. Since `found` is never recomputed after `ext` is replaced by the catchall lookup, inverted lookups (NFT_LOOKUP_F_INV, \"!= @set\") can wrongly match or wrongly skip the catchall element, producing the wrong verdict. Fold the catchall lookup into `ext` before computing `found`, matching the order already used by nft_objref_map_eval().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72366", "url": "https://ubuntu.com/security/CVE-2026-72366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_create_write_req() to handle async cache object creation netfs_create_write_req() will skip caching if the fscache cookie is disabled, but this is a problem because async cache object creation might not have got far enough yet that has been enabled - thereby causing the call to fscache_begin_write_operation() to be skipped. Fix this by removing the checks on the cookie and delegating this to fscache_begin_write_operation().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72381", "url": "https://ubuntu.com/security/CVE-2026-72381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d (\"ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd\") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72393", "url": "https://ubuntu.com/security/CVE-2026-72393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: don't cache shinfo across skb realloc fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0 __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0: kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72398", "url": "https://ubuntu.com/security/CVE-2026-72398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: add INIT verification after cookie unpacking In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk. When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe. However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data. Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded. Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk. Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72399", "url": "https://ubuntu.com/security/CVE-2026-72399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: check the number of BDs needed for xdp_frame The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the number of fragments contained in xdp_frame may be greater than or equal to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr to be out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72429", "url": "https://ubuntu.com/security/CVE-2026-72429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix type confusion of dst_entry IOAM uses a dummy dst_entry(null_dst) to mark that the destination should not be changed after the transformation. This dst is stored in the IOAM lwt state and may be passed to dst_cache_set_ip6(). However, the IPv6 dst cache path eventually calls rt6_get_cookie(), which treats the dst_entry as part of a struct rt6_info. Since the null_dst was embedded directly as a struct dst_entry in struct ioam6_lwt, this resulted in an invalid cast and rt6_get_cookie() reading fields from the wrong object. In practice, the wrong cookie is not used while dst->obsolete is zero, but rt6_get_cookie() may also access per-cpu value when rt->sernum is zero. In this case, rt->sernum aliases ioam6_lwt::cache::reset_ts, which can become zero, making this a potential invalid pointer access. Fix this by embedding a full struct rt6_info for the dummy IPv6 route and passing its dst member to the dst APIs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72436", "url": "https://ubuntu.com/security/CVE-2026-72436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types Sashiko pointed out that there are a few lockless RCU readers using test_bit() which is a relaxed atomic operation and provides no memory barrier guarantees. Use test_bit_acquire() instead where the operation may run parallel with add/del/gc, i.e. is not one from the next cases - protected by region lock - in a set destroy phase - in a new/temporary set creation phase", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72451", "url": "https://ubuntu.com/security/CVE-2026-72451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix xfrm state cache insertion race The xfrm input state cache insertion code checks the validity of the state before acquiring the global xfrm_state_lock. Thus it's possible for someone else to kill the state after it passed the validity check, and then the insertion will add the dead state to the cache. Fix this by moving the validity check inside the lock. This entire function is called on the input path, where BH must be off (e.g., the caller of this function xfrm_input acquires its spinlocks without disabling BH). So there is no need to disable BH here or take the RCU read lock. Remove both and replace them with an assertion that trips if BH is accidentally enabled on some future calling path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72472", "url": "https://ubuntu.com/security/CVE-2026-72472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: use nfsi->rwsem to protect traversal of the file lock list Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), it has been resolved after commit 0460253913e5 (\"NFSv4: nfs4_do_open() is incorrectly triggering state recovery\") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72473", "url": "https://ubuntu.com/security/CVE-2026-72473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decouple req recycling from RPC completion rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74310", "url": "https://ubuntu.com/security/CVE-2026-74310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74345", "url": "https://ubuntu.com/security/CVE-2026-74345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix endpoint/socket association handling Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74361", "url": "https://ubuntu.com/security/CVE-2026-74361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: fix FDP fdpcidx bounds check The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdp_idx when it equals n (i.e. NUMFDPC + 1).", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74401", "url": "https://ubuntu.com/security/CVE-2026-74401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as \"before(mh->seq, seq)\" will stop to check for older sequence numbers that are ordered in the tail of \"node->send_queue\". The side effects of not having it correct ordered regarding \"before(mh->seq, seq)\" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74406", "url": "https://ubuntu.com/security/CVE-2026-74406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74428", "url": "https://ubuntu.com/security/CVE-2026-74428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix double unlock in rxrpc_recvmsg() Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74433", "url": "https://ubuntu.com/security/CVE-2026-74433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix UAF in rxgk_issue_challenge() Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74434", "url": "https://ubuntu.com/security/CVE-2026-74434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-74439", "url": "https://ubuntu.com/security/CVE-2026-74439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d (\"iommu/vt-d: Clear Present bit before tearing down context entry\") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the \"Guidance to Software for Invalidations\" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2166443, 2166356, 2165872, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165407, 2165040, 2161748, 2163508, 2163214, 2162904, 2162045, 2164967, 2160082, 2164504, 2156316, 2164716, 2164516, 2163375, 2162803, 2163062, 2132119, 2163293, 2160200, 2158858, 2162704, 2162695, 2164666, 2164666, 2163121 ], "changes": [ { "cves": [ { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-68105", "url": "https://ubuntu.com/security/CVE-2026-68105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix kernel panic during driver load failure Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68109", "url": "https://ubuntu.com/security/CVE-2026-68109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68114", "url": "https://ubuntu.com/security/CVE-2026-68114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68431", "url": "https://ubuntu.com/security/CVE-2026-68431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68138", "url": "https://ubuntu.com/security/CVE-2026-68138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68082", "url": "https://ubuntu.com/security/CVE-2026-68082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-08 10:16:00 UTC" }, { "cve": "CVE-2026-68159", "url": "https://ubuntu.com/security/CVE-2026-68159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68163", "url": "https://ubuntu.com/security/CVE-2026-68163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_vma_mapped: fix device-private PMD handling Commit 65edfda6f3f2 (\"mm/rmap: extend rmap and migration support device-private entries\") introduced the concept of device-private PMD entries, but did not correctly update the rmap walk code to account for them. As a result, when page_vma_mapped_walk() encounters device-private PMD entries, it takes no action other than to acquire the PMD lock and exit. However this is highly problematic for two reasons - firstly, device private entries possess a PFN so check_pmd() needs to be called to ensure an overlapping PFN range. Secondly, and more importantly, if PVMW_MIGRATION is set the caller assumes the returned entry is a migration entry, resulting in memory corruption when the caller tries to interpret the device private entry as such. In addition, commit 146287290023 (\"mm/huge_memory: implement device-private THP splitting\") allowed device private PMDs to be split like THP mappings, but again did not update this code path. As a result, we might race a PMD split prior to acquiring the PMD lock. This patch addresses all of these issues by invoking check_pmd(), ensuring PMVW_MIGRATION is not set and checks whether a split raced us we do for PMD THP and migration entries. Instead of checking for a subset of the cases after taking the pmd_lock(), put device-private along with pmd_trans_huge() and pmd_is_migration_entry(). Also remove thp_migration_supported() as it is already guarded by pmd_is_migration_entry(). [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68166", "url": "https://ubuntu.com/security/CVE-2026-68166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68170", "url": "https://ubuntu.com/security/CVE-2026-68170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix stale skb->sk reference on subflow close The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68177", "url": "https://ubuntu.com/security/CVE-2026-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Delay module ref count for \"enable_event\" trigger Triggers are now delayed from freeing, but can still be triggered until after the RCU grace period has ended. The freeing of the enable_event data is put into the private_data_free() callback, but the put of the module refcount is done immediately. It is possible that if a module is removed that has an event that would enable (or disable) it is still active, it can read the data of the module after it is removed causing a use-after-free bug. Move the trace_event_put_ref() that releases the module into the delayed callback so that the module can not be removed until any reference to its events are finished.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68191", "url": "https://ubuntu.com/security/CVE-2026-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix NULL pointer dereference in rhash table destroy When unbinding the ath12k driver, kernel NULL pointer dereferences occur in irq_work_sync() called from rhashtable_destroy(). Two hash tables are affected: 1. ath12k_link_sta hash table in ath12k_base 2. ath12k_dp_link_peer hash table in ath12k_dp The issue happens because the destroy functions are called unconditionally in cleanup paths, but the hash tables are only initialized late in their respective init functions. If the device was never fully started or if the init functions failed before initializing the hash tables, the pointers will be NULL. The issues are always reproducible from a VM because the MSI addressing initialization is failing. Call trace for ath12k_link_sta_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k] ath12k_core_stop+0xe/0x80 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Call trace for ath12k_dp_link_peer_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k] ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Fix this by adding NULL checks before calling rhashtable_destroy() in both destroy functions. The NULL check approach was chosen because the rhashtable pointer serves as the initialization state indicator. The init can fail at various points, leaving some components uninitialized. Checking the pointer directly is simpler than adding separate state flags that would need synchronization.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64586", "url": "https://ubuntu.com/security/CVE-2026-64586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs \"reset\" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs \"reset\" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68208", "url": "https://ubuntu.com/security/CVE-2026-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: Fix the error code of devm_kzalloc() in vip_probe_slice() In vip_probe_slice(), the error check for devm_kzalloc() incorrectly uses PTR_ERR_OR_ZERO() which returns 0 for NULL pointer. Return -ENOMEM for devm_kzalloc() failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68224", "url": "https://ubuntu.com/security/CVE-2026-68224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mali-c55: Fix possible ERR_PTR in enable_streams The media_pad_remote_pad_unique() function returns either a valid pointer or an ERR_PTR() on failure (-ENOTUNIQ if multiple links are enabled, -ENOLINK if no connected pad is found). The return value was assigned directly to isp->remote_src and dereferenced in the next line without checking for errors, which could lead to an ERR_PTR dereference. Add proper error checking with IS_ERR() before dereferencing the pointer. Also set isp->remote_src to NULL on error to maintain consistency with other error paths in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68237", "url": "https://ubuntu.com/security/CVE-2026-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: fix indefinite fence wait during GPU reset pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue's fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68240", "url": "https://ubuntu.com/security/CVE-2026-68240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: publish dpagemap early to avoid device mapping leak on error drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68242", "url": "https://ubuntu.com/security/CVE-2026-68242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix NULL deref on sched_engine alloc failure Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68254", "url": "https://ubuntu.com/security/CVE-2026-68254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68436", "url": "https://ubuntu.com/security/CVE-2026-68436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use kvzalloc to allocate struct dc struct dc has grown large over time (most of it the two inlined dc_scratch_space copies) and now sits close to the page allocator's 4 MiB contiguous allocation limit. Its actual size is not fixed by the source alone, it also depends on the compiler and the .config, so it can easily cross 4 MiB, e.g. with a newer GCC or a config change. dc_create() allocates it with kzalloc(). Once struct dc exceeds 4 MiB the request is rounded up to order 11 (8 MiB), which is above MAX_PAGE_ORDER, so the page allocator warns and returns NULL. dc_create() then fails, DM init fails and amdgpu probe aborts with -EINVAL: WARNING: mm/page_alloc.c:5197 at __alloc_frozen_pages_noprof+0x2f9/0x380 dc_create+0x38/0x660 [amdgpu] amdgpu_dm_init+0x2d9/0x510 [amdgpu] dm_hw_init+0x1b/0x90 [amdgpu] amdgpu_device_init.cold+0x150d/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x19/0x80 [amdgpu] amdgpu_pci_probe+0x1e2/0x4c0 [amdgpu] dc_create() then returns NULL and DM init fails, which aborts the whole GPU init and makes amdgpu probe fail with -EINVAL (\"hw_init of IP block failed -22\"), leaving the display unusable. The subsequent amdgpu_irq_put() warnings during teardown are just fallout of unwinding a half-initialized device. struct dc is a software-only bookkeeping structure that is never handed to hardware DMA and is only ever kept as an opaque pointer, so it does not require physically contiguous memory. Allocate it with kvzalloc() (and free it with kvfree()) so that the allocator can fall back to vmalloc() when a contiguous allocation of that size is not available, which also avoids the MAX_PAGE_ORDER warning entirely. v2: - Rebase to amd-staging-drm-next. (cherry picked from commit 991e0516a8072f2292681c6ae98a924ab0e32575)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68447", "url": "https://ubuntu.com/security/CVE-2026-68447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3)", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68264", "url": "https://ubuntu.com/security/CVE-2026-68264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: Reset current_op in xe_pt_update_ops_init() xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org (cherry picked from commit 046045543e530605c441063535e7dca0075369a6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68265", "url": "https://ubuntu.com/security/CVE-2026-68265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68267", "url": "https://ubuntu.com/security/CVE-2026-68267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. (cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68273", "url": "https://ubuntu.com/security/CVE-2026-68273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68274", "url": "https://ubuntu.com/security/CVE-2026-68274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68283", "url": "https://ubuntu.com/security/CVE-2026-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free freeing trigger private data Commit 61d445af0a7c (\"tracing: Add bulk garbage collection of freeing event_trigger_data\") moved the kfree() of event_trigger_data to a kthread that runs tracepoint_synchronize_unregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from trigger_data_free(). event_hist_trigger_free(), event_hist_trigger_named_free() and event_enable_trigger_free() free their satellite data (hist_data, cmd_ops, enable_data) right after trigger_data_free() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the list_del_rcu()'d trigger, causing a use-after-free. The histogram teardown must stay synchronous: remove_hist_vars() and unregister_field_var_hists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correct barrier - tracepoint_synchronize_unregister(), matching the free kthread - before freeing. The enable trigger has no such synchronous requirement, and a blocking synchronize there would re-serialize the path that commit deliberately deferred. Give it an optional private_data_free() callback that the free kthread runs after its grace period, and free enable_data from there.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68286", "url": "https://ubuntu.com/security/CVE-2026-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68287", "url": "https://ubuntu.com/security/CVE-2026-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68288", "url": "https://ubuntu.com/security/CVE-2026-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68289", "url": "https://ubuntu.com/security/CVE-2026-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68291", "url": "https://ubuntu.com/security/CVE-2026-68291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68303", "url": "https://ubuntu.com/security/CVE-2026-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68312", "url": "https://ubuntu.com/security/CVE-2026-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing. The cifsFileInfo reference and the open server handle both leak. Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock. Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68316", "url": "https://ubuntu.com/security/CVE-2026-68316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Fix element size accounting for cmd stream validation There are 2 issues with the element size handling in the command stream validation which result in too small of a size calculated when the element size is 16/32/64 bits. For NHWC format, the element size is simply missing from the calculation. The bitfield for the element size is different between IFM/IFM2 and OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM uses bits 1:2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68440", "url": "https://ubuntu.com/security/CVE-2026-68440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix heap overflow when reading module EEPROM txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68323", "url": "https://ubuntu.com/security/CVE-2026-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68441", "url": "https://ubuntu.com/security/CVE-2026-68441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d (\"bpf: add bpf_redirect() helper\"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs. Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working. The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68337", "url": "https://ubuntu.com/security/CVE-2026-68337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject redirect helpers without a bpf_net_context The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \\ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68345", "url": "https://ubuntu.com/security/CVE-2026-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: guard MBWU state before adding it to garbage __destroy_component_cfg() adds each RIS mbwu_state object to the MPAM garbage list when destroying component configuration. However, mbwu_state is allocated per RIS and only for RISes with MBWU monitors. A component can therefore have comp->cfg allocated while some RISes still have ris->mbwu_state set to NULL. Passing a NULL mbwu_state to add_to_garbage() dereferences the NULL pointer inside the macro. Skip RISes that do not have an mbwu_state object before adding them to the garbage list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68347", "url": "https://ubuntu.com/security/CVE-2026-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68375", "url": "https://ubuntu.com/security/CVE-2026-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle partially initialized auxiliary devices bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68382", "url": "https://ubuntu.com/security/CVE-2026-68382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Hold device ref until queue teardown completes GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68383", "url": "https://ubuntu.com/security/CVE-2026-68383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Keep scheduler timeline name alive The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68390", "url": "https://ubuntu.com/security/CVE-2026-68390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups hci_conn_params_lookup requires hdev->lock be held, otherwise the list iteration or param access is not safe. Hold hdev->lock for params lookups in hci_sync.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68404", "url": "https://ubuntu.com/security/CVE-2026-68404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: use wiphy work for socket owner autodisconnect nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68367", "url": "https://ubuntu.com/security/CVE-2026-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68095", "url": "https://ubuntu.com/security/CVE-2026-68095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse-uring: fix race between registration and connection abortion This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls \"wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);\" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68173", "url": "https://ubuntu.com/security/CVE-2026-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: wait on ublk_dev_ready() instead of ub->completion ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an edge-triggered latch used as a proxy for the level condition \"every queue has fetched all I/O commands\", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68113", "url": "https://ubuntu.com/security/CVE-2026-68113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68118", "url": "https://ubuntu.com/security/CVE-2026-68118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68120", "url": "https://ubuntu.com/security/CVE-2026-68120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtase: Workaround for TX hang caused by hardware packet parsing The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68122", "url": "https://ubuntu.com/security/CVE-2026-68122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix peer refcount leak in TCP error paths When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window: CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68128", "url": "https://ubuntu.com/security/CVE-2026-68128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: reject out-of-range ptype in ice_parser_profile_init set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68132", "url": "https://ubuntu.com/security/CVE-2026-68132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68133", "url": "https://ubuntu.com/security/CVE-2026-68133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP Call Trace during PTP release If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68134", "url": "https://ubuntu.com/security/CVE-2026-68134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ptp_s390: Add missing facility check Only register the physical clock when facility 28 is installed and PTFF QAF returns that PTFF QPT is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68150", "url": "https://ubuntu.com/security/CVE-2026-68150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/super: fix emergency thaw double-unlock of s_umount do_thaw_all() iterates over all superblocks via __iterate_supers() with SUPER_ITER_EXCL, which acquires s_umount exclusively before calling the callback and releases it afterwards. However, the callback do_thaw_all_callback() calls thaw_super_locked() which unconditionally releases s_umount on every code path. This results in a second unlock attempt in __iterate_supers() that corrupts the rwsem state, triggering a DEBUG_RWSEMS warning: [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems [ 182.601865] ------------[ cut here ]------------ [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53 [ 182.604578] Modules linked in: [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy) [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 182.606417] Workqueue: events do_thaw_all [ 182.606750] RIP: 0010:up_write+0xaf/0x170 [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246 [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870 [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10 [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80 [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000 [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800 [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000 [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0 [ 182.613722] Call Trace: [ 182.613946] [ 182.614130] __iterate_supers+0x128/0x150 [ 182.614463] do_thaw_all+0x1b/0x30 [ 182.614759] process_scheduled_works+0xbb/0x3f0 [ 182.615150] ? __pfx_worker_thread+0x10/0x10 [ 182.615499] worker_thread+0x129/0x270 [ 182.615816] ? __pfx_worker_thread+0x10/0x10 [ 182.616201] kthread+0xe2/0x120 [ 182.616469] ? __pfx_kthread+0x10/0x10 [ 182.616792] ret_from_fork+0x15b/0x240 [ 182.617115] ? __pfx_kthread+0x10/0x10 [ 182.617426] ret_from_fork_asm+0x1a/0x30 [ 182.617761] [ 182.617968] ---[ end trace 0000000000000000 ]--- [ 182.618412] Emergency Thaw complete Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount in the callback via super_lock_excl() before calling thaw_super_locked(). This matches the locking pattern expected by thaw_super_locked() and eliminates the double unlock. While at it, remove the dead 'return;' at the end of do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68152", "url": "https://ubuntu.com/security/CVE-2026-68152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: fix use-after-free in AMT delayed works When an AMT device is removed, pending delayed works can still access the freed amt_dev structure, which may result in kernel crashes or memory corruption. amt_dev_stop() cancels req_wq and discovery_wq with cancel_delayed_work_sync(), but these works can be scheduled again from event_wq after the cancellation. This allows delayed works to access the freed amt_dev structure after the netdev has been released. The following is a simple race scenario: CPU0 CPU1 amt_dev_stop() cancel_delayed_work_sync() amt_event_work() mod_delayed_work(req_wq) free netdev req_wq accesses freed amt_dev Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and discovery_wq from being queued again and wait for running work items to complete. The delayed works are disabled after initialization in amt_newlink() and enabled only when the device is successfully opened. This keeps the delayed work lifecycle synchronized with the lifetime of the AMT device.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68168", "url": "https://ubuntu.com/security/CVE-2026-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix afs_edit_dir_remove() to get, not find, block 0 Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather than afs_dir_find_block() as the latter caches the found block in the afs_dir_iter and may[*] switch out the page it's on if another afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does. [*] There's more than one block per page.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68169", "url": "https://ubuntu.com/security/CVE-2026-68169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a \"not found\" sentinel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68172", "url": "https://ubuntu.com/security/CVE-2026-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: make huge_ptep_get handled unaligned addresses huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma). The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic. Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68174", "url": "https://ubuntu.com/security/CVE-2026-68174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix union collision of module and refcnt for dynamic events In 'struct trace_event_call', the 'module' pointer and the 'refcnt' atomic variable share the same memory space in a union. For dynamic events, the union member is 'refcnt', which acts as an active reference counter. When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or wprobe) has a non-zero reference count (e.g. due to active event triggers or perf attachments), its 'call->module' evaluates to a small non-zero integer instead of NULL. When filtering or setting events for a specific module (e.g., writing ':mod:' to 'set_event'), the code in '__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads 'call->module' directly without checking whether the event is dynamic. This causes the kernel to treat the small integer (refcnt) as a 'struct module' pointer, leading to a NULL/invalid pointer dereference (Oops) when dereferencing the module name. Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked before treating 'call->module' as a valid pointer in these code paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68434", "url": "https://ubuntu.com/security/CVE-2026-68434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms Commit b1b4efea05a5 (\"serial: 8250_mid: Disable DMA for selected platforms\") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68198", "url": "https://ubuntu.com/security/CVE-2026-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix use-after-free in aggr_reset_state() The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68200", "url": "https://ubuntu.com/security/CVE-2026-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: don't re-enter an instance callback that is still running The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68201", "url": "https://ubuntu.com/security/CVE-2026-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: drain a slave's callback before its master detaches it snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68211", "url": "https://ubuntu.com/security/CVE-2026-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32-dcmipp: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. dcmipp_bytecap_start_streaming() returned -EINVAL when the source subdevice could not be resolved from the media graph, before pm_runtime_resume_and_get() and media_pipeline_start() had been called. The remaining error paths already converge on the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate err_pm_put / err_media_pipeline_stop labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68230", "url": "https://ubuntu.com/security/CVE-2026-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: amlogic-c3: Add validations for ae and awb config Avoid invalid memory access if the zones_num is bigger than zone_weight. This patch fixes the following smatch errors: drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68232", "url": "https://ubuntu.com/security/CVE-2026-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68233", "url": "https://ubuntu.com/security/CVE-2026-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Shut down BO cache timer before teardown The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68238", "url": "https://ubuntu.com/security/CVE-2026-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68239", "url": "https://ubuntu.com/security/CVE-2026-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68241", "url": "https://ubuntu.com/security/CVE-2026-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/mst: limit DP MST ESI service loop The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68245", "url": "https://ubuntu.com/security/CVE-2026-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68252", "url": "https://ubuntu.com/security/CVE-2026-68252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68253", "url": "https://ubuntu.com/security/CVE-2026-68253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68257", "url": "https://ubuntu.com/security/CVE-2026-68257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68258", "url": "https://ubuntu.com/security/CVE-2026-68258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on CRIU restore queue type and mqd size We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68266", "url": "https://ubuntu.com/security/CVE-2026-68266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68268", "url": "https://ubuntu.com/security/CVE-2026-68268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Return error on non-migratable faults requiring devmem Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68270", "url": "https://ubuntu.com/security/CVE-2026-68270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Avoid possible truncation with calculating visible size Calculating the visible size of the system framebuffer can result in truncation of the result. The calculation uses 32-bit arithmetics, which can overflow if the values for height and stride are large. Fix the issue by multiplying with mul_u32_u32().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68275", "url": "https://ubuntu.com/security/CVE-2026-68275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68276", "url": "https://ubuntu.com/security/CVE-2026-68276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: fix cleaner shader IB buffer overflow The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68282", "url": "https://ubuntu.com/security/CVE-2026-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Add missing error check for platform_get_resource() Add missing error check for platform_get_resource() return value to prevent NULL pointer dereference when memory resource is not available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68292", "url": "https://ubuntu.com/security/CVE-2026-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68296", "url": "https://ubuntu.com/security/CVE-2026-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM Before commit 00d066a4d4ed (\"netdev_features: convert NETIF_F_LLTX to dev->lltx\"), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev->features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev->lltx flag, it placed 'dev->lltx = true' after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); Fix by moving dev->lltx = true before the early returns in both functions, restoring the original unconditional behavior.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64575", "url": "https://ubuntu.com/security/CVE-2026-64575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: fix double sock release on batch realloc bpf_iter_tcp_batch() releases the current batch via bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites each slot with the socket cookie, then grows the batch. cur_sk/end_sk are kept for bpf_iter_tcp_resume(), but on realloc failure the function returns ERR_PTR() before resume runs, leaving cur_sk < end_sk over slots that now hold cookies rather than sock pointers. bpf_iter_tcp_seq_stop() then calls bpf_iter_tcp_put_batch() again and dereferences a cookie as a struct sock. Empty the batch on the failure path so stop() does not release it again. The sockets were already freed by the first bpf_iter_tcp_put_batch(), so nothing leaks, and a later read() rescans the bucket from the start instead of skipping it. The sibling GFP_NOWAIT failure path still holds real socket references and is left for stop() to release. BUG: KASAN: null-ptr-deref in __sock_gen_cookie Read of size 8 at addr 0000000000000059 by task exploit ... __sock_gen_cookie (net/core/sock_diag.c:28) bpf_iter_tcp_put_batch (net/ipv4/tcp_ipv4.c:2918) bpf_iter_tcp_seq_stop (net/ipv4/tcp_ipv4.c:3270) bpf_seq_read (kernel/bpf/bpf_iter.c:205) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 entry_SYSCALL_64_after_hwframe Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68298", "url": "https://ubuntu.com/security/CVE-2026-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create() Commit 9e9787414882 (\"drm/xe/userptr: replace xe_hmm with gpusvm\") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a \"simple\" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68448", "url": "https://ubuntu.com/security/CVE-2026-68448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: check access to copy_file_range source with src mounter creds Commit 5dae222a5ff0c (\"vfs: allow copy_file_range to copy across devices\") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type. The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs. The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time. While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds. This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied. Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds. The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68307", "url": "https://ubuntu.com/security/CVE-2026-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix crash in reset link replay During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif->valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &vif->bss_conf for the legacy link.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68311", "url": "https://ubuntu.com/security/CVE-2026-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: guard link STA in decap offload mt7925_sta_set_decap_offload() iterates over the vif valid_links mask when updating decap offload state for an MLO station. The station may not have a link STA for every valid link of the vif, so mt792x_sta_to_link() can return NULL for a link that belongs to the vif but not to the station. The function currently dereferences mlink before checking whether the link WCID is ready. If mlink is NULL, setting or clearing MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer. Skip links without a station link before touching mlink->wcid.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68321", "url": "https://ubuntu.com/security/CVE-2026-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix FDIR filter leak on remove Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68330", "url": "https://ubuntu.com/security/CVE-2026-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix DMA direction for NPU mailbox buffer airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations. Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures dma_unmap_single() invalidates the CPU cache on non-coherent systems. The mailbox buffers are small so there is no performance concern.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68332", "url": "https://ubuntu.com/security/CVE-2026-68332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix potential use-after-free in airoha_ppe_deinit() airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 (\"net: airoha: Fix schedule while atomic in airoha_ppe_deinit()\") omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68334", "url": "https://ubuntu.com/security/CVE-2026-68334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68341", "url": "https://ubuntu.com/security/CVE-2026-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix use after free in unlock_ovpn() unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68342", "url": "https://ubuntu.com/security/CVE-2026-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: avoid putting unrelated P2P peer on socket release ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68356", "url": "https://ubuntu.com/security/CVE-2026-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: airoha: Prevent division by zero when clock frequency is zero clk_get_rate() can return 0 when the clock provider is not properly configured or the clock is unmanaged. The driver uses wdt_freq as a divisor directly in airoha_wdt_probe() to compute max_timeout and in airoha_wdt_get_timeleft() to compute the remaining time, which results in a division by zero. Add a check for wdt_freq == 0 in probe and return -EINVAL with dev_err_probe() to prevent the division by zero and provide a diagnostic message.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68358", "url": "https://ubuntu.com/security/CVE-2026-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-kraken3) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68374", "url": "https://ubuntu.com/security/CVE-2026-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: sysfs: add lock to bos_descriptors_read() Add a lock to the function bos_descriptors_read(). This function accesses udev->bos, which could be simultaneously freed in usb_reset_and_verify_device(), a function that is commonly called in drivers all over the kernel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68378", "url": "https://ubuntu.com/security/CVE-2026-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68379", "url": "https://ubuntu.com/security/CVE-2026-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TIME_WAIT socket reference leak on PSP policy failure Release the TIME_WAIT socket reference and jump to discard_it upon PSP policy failure in both IPv4 and IPv6 receive paths. This prevents a memory leak of tcp_tw_bucket structures.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68380", "url": "https://ubuntu.com/security/CVE-2026-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix use-after-free of mm_struct in job scheduler amdxdna_cmd_submit() stores current->mm in job->mm without holding any reference. aie2_sched_job_run() later access job->mm from the DRM scheduler worker thread. With only a raw pointer and no structural reference, the mm_struct can be freed before the scheduler runs the job. Fix this by calling mmgrab() to hold a structural mm_count reference for the lifetime of the job, paired with mmdrop() in every cleanup path.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68384", "url": "https://ubuntu.com/security/CVE-2026-68384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68385", "url": "https://ubuntu.com/security/CVE-2026-68385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/checksum: Fix csum_partial() without vector facility Currently csum_partial() calls csum_copy() with copy=false and dst=NULL. On machines without the vector facility, csum_copy() falls back to cksm(dst, ...), causing the checksum to be calculated from address zero instead of the source buffer. The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68387", "url": "https://ubuntu.com/security/CVE-2026-68387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: add locking for raw flags bitfield With commit 890e5198a6e5 (\"can: raw: use bitfields to store flags in struct raw_sock\") the formerly separate integer values have been integrated into a single bitfield. This led to a read-modify-write operation when changing a flag in raw_setsockopt() which now needs a locking to prevent concurrent access. Instead of adding a lock/unlock hell in each of the flag manipulations this patch introduces a wrapper for a new raw_setsockopt_locked() function analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c [mkl: use Closes tag instead of Link]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68393", "url": "https://ubuntu.com/security/CVE-2026-68393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: extend conn_hash lookup critical sections Using RCU-protected pointers outside the critical sections without refcount is incorrect and may result to UAF. Extend critical section to cover both hci_conn_hash lookup and use of the returned conn. Add surrounding rcu_read_lock() also when return value is not used, in preparation for RCU lockdep requirement to hci_lookup_le_connect(). This avoids concurrent deletion of the conn before we are done dereferencing it. Also, make sure to hold hdev->lock when accessing hdev->accept_list.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68394", "url": "https://ubuntu.com/security/CVE-2026-68394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter update changes an existing LE central connection. The queued work currently stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later LOAD_CONN_PARAM request can clear disabled parameters and free that entry before hci_cmd_sync_work() runs the queued callback. Do not keep the borrowed hci_conn_params pointer in queued work. Queue the hci_conn instead and hold a reference until the queued callback completes. When the work runs, revalidate that the connection is still present, look up the current hci_conn_params entry, and cancel the update if userspace removed that entry while the work was pending. Copy the interval values from the current params entry under hdev->lock, then drop the lock and keep using hci_le_conn_update_sync() to issue the update. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth] Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Allocated by task 466: hci_conn_params_add+0xa6/0x240 [bluetooth] load_conn_param+0x4e1/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Freed by task 474: kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth] load_conn_param+0x4bf/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68400", "url": "https://ubuntu.com/security/CVE-2026-68400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint memory access array and to comply with the FF-A spec instead of defaulting to `sizeof(struct ffa_mem_region)`. This requires moving `ffa_mem_region_additional_setup()` earlier in the setup flow. Also, add sanity checks to ensure the calculated descriptor offsets do not exceed `max_fragsize`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68401", "url": "https://ubuntu.com/security/CVE-2026-68401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() Sashiko (locally) reports multiple out-of-bound issues in ffa_setup_and_transmit: 1) Writing ep_mem_access->reserved can write out of bounds for FFA versions < 1.2 as ffa_emad_size_get() returns 16 bytes in that case while reserved has an offset of 24. Instead of zeroing fields, memset the struct to zero first based on the FFA version. 2) Make sure there is enough size to write constituents. While at it, convert the only sizeof() in the driver that uses a type instead of variable.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68409", "url": "https://ubuntu.com/security/CVE-2026-68409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: defer link RX stats percpu free to RCU sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU: \tsta_info_free_link(&alloc->info); \tkfree_rcu(alloc, rcu_head); The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists. The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU. Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68412", "url": "https://ubuntu.com/security/CVE-2026-68412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan() If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. Use the existing error handling path to fix it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64566", "url": "https://ubuntu.com/security/CVE-2026-64566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68415", "url": "https://ubuntu.com/security/CVE-2026-68415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear mode callbacks after failed mode setup xfrm_state_gc_task can run long after a failed IPTFS state setup. In the reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup returned -ENOMEM before publishing mode_data, and the temporary module reference from xfrm_get_mode_cbs() was dropped immediately. The dead state then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been unloaded. Clear x->mode_cbs when mode init or clone fails before publishing mode_data. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference. The buggy scenario involves two paths, with each column showing the order within that path: failed setup path: 1. cache x->mode_cbs 2. mode setup fails before mode_data 3. drop the temporary module ref 4. dead state keeps x->mode_cbs cached GC/unload path: 1. xfrm_state_put() queues GC work 2. xfrm_iptfs unloads later 3. xfrm_state_gc_task runs 4. GC dereferences stale x->mode_cbs This also covers the failed clone path where clone_state() returns before publishing mode_data. Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y failslab_stacktrace_filter matched xfrm_iptfs frames ack_error=-12 FAULT_INJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrm_state_gc_task RIP: xfrm_state_gc_task+0x142/0x650 Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs] Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68418", "url": "https://ubuntu.com/security/CVE-2026-68418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent user-triggered null deref on QP create Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp. While there was a check for iwqp->iwpbl != NULL, this check would only occur if req.user_wqe_bufs was non-zero. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref. Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68420", "url": "https://ubuntu.com/security/CVE-2026-68420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: reject optional IPTFS templates in outbound policies syzbot reported a stack-out-of-bounds read in xfrm_state_find() which flows from xfrm_tmpl_resolve_one(). Commit 3d776e31c841 (\"xfrm: Reject optional tunnel/BEET mode templates in outbound policies\") disallowed optional tunnel and BEET in outbound policies to prevent this. Later when IPTFS added, it was not covered by that fix and can still trigger the out-of-bounds read; Extend the check to disallow optional IPTFS in outbound policies as well. IPTFS should be identical to tunnel mode. IN and FWD policies are not affected: xfrm_tmpl_resolve_one() is only reachable via the outbound path. Reproducer, before: ip link add dummy0 type dummy ip link set dummy0 up ip addr add 10.1.1.1/24 dev dummy0 ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 mode transport ping -W 1 -c 1 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. [ 64.168420] ================================================================== [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844 [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full) [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 64.169977] Call Trace: [ 64.169977] [ 64.169977] dump_stack_lvl+0x47/0x70 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] print_report+0x152/0x4b0 [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0 [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __virt_addr_valid+0x21b/0x230 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] kasan_report+0xa8/0xd0 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm_dst_hash+0x24/0xc0 [ 64.169977] xfrm_state_find+0xa2d/0x2f90 [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570 [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10 [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 64.169977] ? kernel_text_address+0x5b/0x80 [ 64.169977] ? __kernel_text_address+0xe/0x30 [ 64.169977] ? unwind_get_return_address+0x5e/0x90 [ 64.169977] ? arch_stack_walk+0x8c/0xe0 [ 64.169977] xfrm_tmpl_resolve+0x130/0x200 [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10 [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110 [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10 [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310 [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80 [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10 [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110 [ 64.169977] ? kasan_save_track+0x10/0x30 [ 64.169977] xfrm_lookup_route+0x18/0xe0 [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530 [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 64.169977] ? do_raw_spin_lock+0x71/0xc0 [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 64.169977] release_sock+0xb0/0x170 [ 64.169977] udp_connect+0x43/0x50 [ 64.169977] __sys_connect+0xa6/0x100 [ 64.169977] ? alloc_fd+0x2e9/0x300 [ 64.169977] ? __pfx___sys_connect+0x10/0x10 [ 64.169977] ? preempt_latency ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68421", "url": "https://ubuntu.com/security/CVE-2026-68421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() put_prev_task_scx() warns when a runnable task drops to a lower sched_class without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have kept it running. Core scheduling breaks that: a forced-idle SMT sibling reschedules through the core_pick fast path in pick_next_task(), which skips pick_task_scx() and thus balance_one(), so a runnable task can drop to idle with ENQ_LAST unset. Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core scheduling forced the idle, while a match (or core scheduling off) still catches a genuine missing-ENQ_LAST drop.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68426", "url": "https://ubuntu.com/security/CVE-2026-68426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix stale skb->prev after async crypto steals a GSO segment skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev). When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free. Repoint skb->prev at the last retained segment before returning.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2023-20585", "url": "https://ubuntu.com/security/CVE-2023-20585", "cve_description": "Insufficient checks of the RMP on host buffer access in IOMMU may allow an attacker with privileges and a compromised hypervisor to trigger an out of bounds condition without RMP checks, resulting in a potential loss of confidential guest integrity.", "cve_priority": "low", "cve_public_date": "2026-04-16 19:16:00 UTC" }, { "cve": "CVE-2026-68364", "url": "https://ubuntu.com/security/CVE-2026-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72064", "url": "https://ubuntu.com/security/CVE-2026-72064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Sync page pool RX frags for CPU MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72098", "url": "https://ubuntu.com/security/CVE-2026-72098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: fix buffer overflow in FEC calculation There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) \tfio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72248", "url": "https://ubuntu.com/security/CVE-2026-72248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei .", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72249", "url": "https://ubuntu.com/security/CVE-2026-72249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72287", "url": "https://ubuntu.com/security/CVE-2026-72287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the \"normal\" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a \"late\" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72329", "url": "https://ubuntu.com/security/CVE-2026-72329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/liquidio: drop cached VF pci_dev LUT The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72355", "url": "https://ubuntu.com/security/CVE-2026-72355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix barriering when walking subrequest list Fix the barriering used when walking the subrequest list in retry as there's a possibility of seeing a subreq that's just been added by the application thread.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72412", "url": "https://ubuntu.com/security/CVE-2026-72412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix handling of _PAGE_UNUSED pte bit The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72417", "url": "https://ubuntu.com/security/CVE-2026-72417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72442", "url": "https://ubuntu.com/security/CVE-2026-72442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix and simplify IP6IP6 tunnel handling Fix nf_flow_ip6_tunnel_proto() to use pskb_may_pull() instead of skb_header_pointer() to ensure the outer IPv6 header is in the skb headroom, which is required for subsequent packet processing. Move ctx->offset update inside the IPPROTO_IPV6 conditional block since it should only be adjusted when an IP6IP6 tunnel is actually detected. Simplify the rx path by removing ipv6_skip_exthdr() and checking ip6h->nexthdr directly, as the flowtable fast path only handles simple IP6IP6 encapsulation without extension headers. Drop the tunnel encapsulation limit destination option support from the tx path to match, since the rx path no longer handles extension headers. Remove the encap_limit parameter from nf_flow_offload_ipv6_forward(), nf_flow_tunnel_ip6ip6_push() and nf_flow_tunnel_v6_push(), along with the ipv6_tel_txoption struct and related headroom/MTU adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72463", "url": "https://ubuntu.com/security/CVE-2026-72463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix dev use-after-free in xfrm async resumption xfrm async resumption hold skb->dev refcnt until after transport_finish. However, xfrm_rcv_cb may modify skb->dev to tunnel dev without taking device reference, such as vti_rcv_cb. The subsequent async resumption will decrement the tunnel device's reference count, which lead to uaf of tunnel dev and refcnt leak of orig dev as below: unregister_netdevice: waiting for vti1 to become free. Usage count = -2 Stash the original skb->dev to fix refcnt imbalance. The new skb->dev set by xfrm_rcv_cb can race with device teardown. Extend rcu protection over xfrm_rcv_cb and transport_finish to prevent races.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72477", "url": "https://ubuntu.com/security/CVE-2026-72477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: call _ntfs_bad_inode() when failing to rename It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce (\"fs/ntfs3: Exclude call make_bad_inode for live nodes.\") The WARN_ON was added when it wasn't safe by: commit d99208b91933 (\"fs/ntfs3: cancle set bad inode after removing name fails\") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72493", "url": "https://ubuntu.com/security/CVE-2026-72493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: serialize netif_running() check in enqueue_to_backlog() Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 (\"net: do not process device backlog during unregistration\") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72494", "url": "https://ubuntu.com/security/CVE-2026-72494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Replace waitqueue and flag with completion The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72496", "url": "https://ubuntu.com/security/CVE-2026-72496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74269", "url": "https://ubuntu.com/security/CVE-2026-74269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt: fix head underflow on XDP head-grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74350", "url": "https://ubuntu.com/security/CVE-2026-74350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate fast symlink target during inode read ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72495", "url": "https://ubuntu.com/security/CVE-2026-72495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72501", "url": "https://ubuntu.com/security/CVE-2026-72501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Initialize dpi variable to zero dpi is initialized only for BNXT_RE_ALLOC_WC_PAGE, but copied for all the cases. So initialize the dpi to 0.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72278", "url": "https://ubuntu.com/security/CVE-2026-72278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68083", "url": "https://ubuntu.com/security/CVE-2026-68083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix path resolution in ksmbd_vfs_kern_path_create The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an absolute path with convert_to_unix_name() and resolves it from AT_FDCWD via start_creating_path(), so a \"..\" component is walked from the real filesystem root and escapes the export. An authenticated client races a missing path component so the rooted open lookup returns -ENOENT (taking the create branch) while the same component is present (a directory) when the create walk runs; the create then resolves \"..\" out of the share. Root the create walk at the share like the lookup and rename paths already are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH, &share_conf->vfs_path) and create the final component with start_creating_noperm(). convert_to_unix_name() then has no callers and is removed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-68457", "url": "https://ubuntu.com/security/CVE-2026-68457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for FSCTL mutations SET_SPARSE, SET_ZERO_DATA and SET_COMPRESSION operate on an open SMB handle but call VFS xattr, fallocate or fileattr helpers with the current ksmbd worker credentials. Those helpers can revalidate inode permissions, ownership and LSM policy independently of the SMB handle access mask. Run each operation with the credentials captured in the target file when the handle was opened. Keep credential handling local to these single-file FSCTLs rather than applying session credentials to the complete IOCTL handler, which also contains handle-less and multi-handle operations.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72041", "url": "https://ubuntu.com/security/CVE-2026-72041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: use sk_msg_free_partial to fix partial send sk_msg_free_partial() ensures consistency of the skmsg at every iteration, without having to manually handle uncharges and offsets. This simplifies the code, and fixes some bugs in skmsg accounting when we don't send the full contents.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72046", "url": "https://ubuntu.com/security/CVE-2026-72046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72137", "url": "https://ubuntu.com/security/CVE-2026-72137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: nat_keepalive: avoid double free on send error nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72139", "url": "https://ubuntu.com/security/CVE-2026-72139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: \tif (needs_md5) { \t\ttcp_ao_destroy_sock(sk, false); \t} else if (needs_ao) { \t\ttcp_clear_md5_list(sk); \t\tkfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); \t} Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72191", "url": "https://ubuntu.com/security/CVE-2026-72191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: validate split-point offset in indx_insert_into_buffer indx_insert_into_buffer() computes used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off)); where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes. A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel. Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount). Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns. A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e (\"fs/ntfs3: Fix OOB read in indx_insert_into_buffer\") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72217", "url": "https://ubuntu.com/security/CVE-2026-72217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it. rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes. Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72220", "url": "https://ubuntu.com/security/CVE-2026-72220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72221", "url": "https://ubuntu.com/security/CVE-2026-72221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72222", "url": "https://ubuntu.com/security/CVE-2026-72222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: pin svc_xprt across the asynchronous TLS handshake callback svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of(). Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done. The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry. Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all(). [cel: rewrote commit message to describe the actual change]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72277", "url": "https://ubuntu.com/security/CVE-2026-72277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72279", "url": "https://ubuntu.com/security/CVE-2026-72279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint. Conveniently, this also plugs a page leak found by Sashiko [*] resulting from the early return for a read-only PFN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72288", "url": "https://ubuntu.com/security/CVE-2026-72288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72317", "url": "https://ubuntu.com/security/CVE-2026-72317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: pin upper rpc_clnt across the TLS connect_worker The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72318", "url": "https://ubuntu.com/security/CVE-2026-72318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate DFS referral string offsets parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server. Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds. Validate each string offset before deriving the string pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72320", "url": "https://ubuntu.com/security/CVE-2026-72320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_lookup: fix catchall element handling with inverted lookups nft_lookup_eval() decides whether a lookup matched (`found`) from the direct set lookup and priv->invert before falling back to the catchall element used by interval sets (e.g. nft_set_rbtree) for the open-ended default range. Since `found` is never recomputed after `ext` is replaced by the catchall lookup, inverted lookups (NFT_LOOKUP_F_INV, \"!= @set\") can wrongly match or wrongly skip the catchall element, producing the wrong verdict. Fold the catchall lookup into `ext` before computing `found`, matching the order already used by nft_objref_map_eval().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72366", "url": "https://ubuntu.com/security/CVE-2026-72366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_create_write_req() to handle async cache object creation netfs_create_write_req() will skip caching if the fscache cookie is disabled, but this is a problem because async cache object creation might not have got far enough yet that has been enabled - thereby causing the call to fscache_begin_write_operation() to be skipped. Fix this by removing the checks on the cookie and delegating this to fscache_begin_write_operation().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72381", "url": "https://ubuntu.com/security/CVE-2026-72381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d (\"ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd\") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72393", "url": "https://ubuntu.com/security/CVE-2026-72393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: don't cache shinfo across skb realloc fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0 __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0: kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72398", "url": "https://ubuntu.com/security/CVE-2026-72398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: add INIT verification after cookie unpacking In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk. When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe. However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data. Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded. Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk. Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72399", "url": "https://ubuntu.com/security/CVE-2026-72399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: check the number of BDs needed for xdp_frame The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the number of fragments contained in xdp_frame may be greater than or equal to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr to be out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72429", "url": "https://ubuntu.com/security/CVE-2026-72429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix type confusion of dst_entry IOAM uses a dummy dst_entry(null_dst) to mark that the destination should not be changed after the transformation. This dst is stored in the IOAM lwt state and may be passed to dst_cache_set_ip6(). However, the IPv6 dst cache path eventually calls rt6_get_cookie(), which treats the dst_entry as part of a struct rt6_info. Since the null_dst was embedded directly as a struct dst_entry in struct ioam6_lwt, this resulted in an invalid cast and rt6_get_cookie() reading fields from the wrong object. In practice, the wrong cookie is not used while dst->obsolete is zero, but rt6_get_cookie() may also access per-cpu value when rt->sernum is zero. In this case, rt->sernum aliases ioam6_lwt::cache::reset_ts, which can become zero, making this a potential invalid pointer access. Fix this by embedding a full struct rt6_info for the dummy IPv6 route and passing its dst member to the dst APIs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72436", "url": "https://ubuntu.com/security/CVE-2026-72436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types Sashiko pointed out that there are a few lockless RCU readers using test_bit() which is a relaxed atomic operation and provides no memory barrier guarantees. Use test_bit_acquire() instead where the operation may run parallel with add/del/gc, i.e. is not one from the next cases - protected by region lock - in a set destroy phase - in a new/temporary set creation phase", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72451", "url": "https://ubuntu.com/security/CVE-2026-72451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix xfrm state cache insertion race The xfrm input state cache insertion code checks the validity of the state before acquiring the global xfrm_state_lock. Thus it's possible for someone else to kill the state after it passed the validity check, and then the insertion will add the dead state to the cache. Fix this by moving the validity check inside the lock. This entire function is called on the input path, where BH must be off (e.g., the caller of this function xfrm_input acquires its spinlocks without disabling BH). So there is no need to disable BH here or take the RCU read lock. Remove both and replace them with an assertion that trips if BH is accidentally enabled on some future calling path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72472", "url": "https://ubuntu.com/security/CVE-2026-72472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: use nfsi->rwsem to protect traversal of the file lock list Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), it has been resolved after commit 0460253913e5 (\"NFSv4: nfs4_do_open() is incorrectly triggering state recovery\") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72473", "url": "https://ubuntu.com/security/CVE-2026-72473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decouple req recycling from RPC completion rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74310", "url": "https://ubuntu.com/security/CVE-2026-74310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74345", "url": "https://ubuntu.com/security/CVE-2026-74345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix endpoint/socket association handling Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74361", "url": "https://ubuntu.com/security/CVE-2026-74361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: fix FDP fdpcidx bounds check The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdp_idx when it equals n (i.e. NUMFDPC + 1).", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74401", "url": "https://ubuntu.com/security/CVE-2026-74401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as \"before(mh->seq, seq)\" will stop to check for older sequence numbers that are ordered in the tail of \"node->send_queue\". The side effects of not having it correct ordered regarding \"before(mh->seq, seq)\" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74406", "url": "https://ubuntu.com/security/CVE-2026-74406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74428", "url": "https://ubuntu.com/security/CVE-2026-74428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix double unlock in rxrpc_recvmsg() Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74433", "url": "https://ubuntu.com/security/CVE-2026-74433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix UAF in rxgk_issue_challenge() Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74434", "url": "https://ubuntu.com/security/CVE-2026-74434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-74439", "url": "https://ubuntu.com/security/CVE-2026-74439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d (\"iommu/vt-d: Clear Present bit before tearing down context entry\") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the \"Guidance to Software for Invalidations\" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" } ], "log": [ "", " * resolute/linux: 7.0.0-38.38 -proposed tracker (LP: #2166443)", "", " * linux: dtbs_install fails on Resolute builders due to uutils install(1)", " EEXIST race under parallel make (LP: #2166356)", " - SAUCE: [Packaging] Serialise dtbs_install to work around uutils", " install(1) race", "", " * #510/p sleepable raw tracepoint reject from test_verifier in ubuntu_bpf", " failed with resolute (7.0.0-33.33) generic amd64 (LP: #2165872)", " - SAUCE: Revert \"bpf: Verifier support for sleepable tracepoint programs\"", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189)", " - platform/x86/intel-uncore-freq: Fix current_freq_khz after CPU hotplug", " - selftests/bpf: Add tests for ld_{abs,ind} failure path in subprogs", " - drm/virtio: fix deadlock in display_info_cb by removing hotplug from", " dequeue worker", " - seqlock: Allow UBSAN_ALIGNMENT to fail optimizing", " - KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN", " - crypto: tegra - Don't touch bo refcount in host1x bo pin/unpin", " - xprtrdma: Clear receive-side ownership pointers on release", " - Input: ims-pcu - fix logic error in packet reset", " - fuse: fix writeback array overflow when max_pages is one", " - arm64: tegra: Remove fallback compatible for GPCDMA", " - arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234", " - xfrm: propagate -EINPROGRESS from validate_xmit_xfrm()", " - mtd: mtdswap: remove debugfs stats file on teardown", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - btrfs: fallback to transaction csum tree on a commit root csum miss", " - RDMA/cma: Fix hardware address comparison length in netevent callback", " - RDMA/irdma: Remove redundant legacy_mode checks", " - RDMA/erdma: initialize ret for empty receive WR lists", " - RDMA/mana_ib: initialize err for empty send WR lists", " - RDMA/hns: Fix potential integer overflow in mhop hem cleanup", " - selftests/alsa: Fix memory leak in find_controls error path", " - RDMA/irdma: Prevent overflows in memory contiguity checks", " - wifi: cfg80211: derive S1G beacon TSF from S1G fields", " - wifi: nl80211: validate nested MBSSID IE blobs", " - wifi: nl80211: constrain MBSSID TX link ID range", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - wifi: mac80211: avoid non-S1G AID fallback for S1G assoc", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: amd: ps: disable MSI on resume in ACP PCI driver", " - ASoC: amd: ps: fix wrong ACP version string in pci_request_regions()", " - ASoC: amd: ps: replace bitwise OR with logical OR in IRQ return check", " - ASoC: cs42l43: Correct report for forced microphone jack", " - ASoC: tas2562: fix deprecated 'shut-down' GPIO always cleared after", " lookup", " - firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context", " - cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - ata: sata_dwc_460ex: use platform_get_irq()", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - accel/ivpu: Fix wrong register read in LNL failure diagnostics", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - powerpc/85xx: Add fsl,ifc to common device ids", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - drm/panthor: Check debugfs GEM lock initialization", " - riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()", " - can: j1939: fix lockless local-destination check", " - drm/xe/wopcm: fix WOPCM size for LNL+", " - drm/i915/wm: clear the plane ddb_y entries on plane disable", " - drm/i915/selftests: Fix GT PM sort comparators", " - USB: storage: add NO_ATA_1X quirk for Longmai USB Key", " - usb: chipidea: fix usage_count leak when autosuspend_delay is negative", " - USB: gadget: snps-udc: fix device name leak on probe failure", " - USB: gadget: fsl-udc: fix device name leak on probe failure", " - USB: gadget: fsl-udc: fix dev_printk() device", " - USB: serial: ftdi_sio: add support for E+H FXA291", " - USB: serial: keyspan_pda: fix data loss on receive throttling", " - USB: serial: option: add TDTECH MT5710-CN", " - SAUCE: Revert \"usb: typec: ucsi: Detect and skip duplicate altmodes from", " buggy firmware\"", " - usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware", " - wifi: mwifiex: fix freeze for 60 seconds caused by request_firmware", " - RISC-V: KVM: Serialize virtual interrupt pending state updates", " - Revert \"drm/amd/display: Add missing kdoc for ALLM parameters\"", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - selftests/bpf: Adjust verifier_map_ptr for the map's excl field", " - selftests/bpf: Keep verifier_map_ptr exercising ops pointer access", " - wifi: ath11k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - wifi: ath12k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - btrfs: declare btrfs_ioctl_search_args_v2::buf as __u8", " - btrfs: fix u32 to s64 type conversion in dirty_metadata_bytes accounting", " - ASoC: sun4i-codec: Set quirks.playback_only for H616 codec", " - ASoC: bt-sco: fix duplicate DAPM widget names for wideband DAI", " - ASoC: cs35l56: Don't use devres to unregister component", " - ASoC: cs35l56: Fix potential probe() deadlock", " - ASoC: cs35l56: Use complete_all() to signal init_completion", " - wifi: iwlwifi: mvm: validate SAR GEO response payload size", " - wifi: iwlwifi: fix pointer arithmetic in iwl_add_mcc_to_tas_block_list", " - wifi: iwlwifi: validate payload length in iwl_pnvm_complete_fn", " - wifi: iwlwifi: mvm: fix read in wake packet notification handler", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - drivers/virt: pkvm: Fix end calculation in mmio_guard_ioremap_hook()", " - hwmon: (asus-ec-sensors) fix looping over banks while reading from EC", " - hwmon: (asus-ec-sensors) fix EC read intervals", " - hwmon: (asus-ec-sensors) add missed handle for ENOMEM", " - selftests/net: ovpn: fix getaddrinfo memory leak in ovpn_parse_remote()", " - ovpn: use monotonic clock for peer keepalive timeouts", " - regulator: mt6358: use regmap helper to read fixed LDO calibration", " - net: phy: marvell: fix return code", " - netlink: specs: rt-link: convert bridge port flag attributes to u8", " - gtp: parse extension headers before reading inner protocol", " - vhost-net: fix TX stall when vhost owns virtio-net header", " - wifi: mac80211: recalculate TIM when a station enters power save", " - pds_core: reject component parameter in legacy firmware update", " - arm64: Correct value returned by ESR_ELx_FSC_ADDRSZ_nL()", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - soreuseport: Clear sk_reuseport_cb before failure in sk_clone().", " - net: Call net_enable_timestamp() before failure in sk_clone().", " - pds_core: yield the CPU while waiting for the adminq to drain", " - pds_core: order completion reads after the ownership check", " - pds_core: check for workqueue allocation failure", " - tls: device: push pending open record on splice EOF", " - selftests: af_unix: add USER_NS config", " - selftests: openvswitch: add config file", " - selftests: ovpn: add IPV6 and VETH configs", " - selftests: ovpn: increase timeout", " - selftests: drv-net: increase timeout", " - ppp: don't store tx skb in the fastpath", " - ppp: annotate concurrent dev->stats accesses", " - ovl: fix trusted xattr escape prefix matching", " - drm/panel: s6e3ha8: fix unmet dependency on DRM_DISPLAY_HELPER", " - amt: make the head writable before rewriting the L2 header", " - net: bridge: vlan: fix vlan range dumps starting with pvid", " - net: dpaa: fix mode setting", " - drm/xe/i2c: Allow per domain unique id", " - iomap: correct the range of a partial dirty clear", " - drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem", " - net: stmmac: xgmac: fix l4 filter port overwrite on register update", " - net: stmmac: fix l3l4 filter rejecting unsupported offload requests", " - net: stmmac: reset residual action in L3L4 filters on delete", " - net: stmmac: enable the MAC on link up for all supported speeds", " - octeontx2-vf: set TC flower flag on MCAM entry allocation", " - ipv4: icmp: fill flow parameters in icmp_route_lookup decoy lookup", " - ppp: annotate data races in ppp_generic", " - hinic: remove unused ethtool RSS user configuration buffers", " - raw: annotate lockless match fields in raw_v4_match()", " - net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan rule", " - net/mlx5e: Report zero bandwidth for non-ETS traffic classes", " - net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation", " - octeontx2-pf: tc: fix egress ratelimiting", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV", " - ice: fix LAG recipe to profile association", " - ipv6: Change allocation flags to match rcu_read_lock section", " requirements", " - ptp: netc: explicitly clear TMR_OFF during initialization", " - mctp: check register_netdevice_notifier() error in mctp_device_init()", " - net: airoha: fix ETS channel derivation in airoha_tc_setup_qdisc_ets()", " - drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay", " - drm: renesas: rzg2l_mipi_dsi: Move rzg2l_mipi_dsi_set_display_timing()", " - drm/tidss: Fix missing drm_bridge_add() call", " - drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video()", " - drm/amdgpu/uvd: Fix forcing MSG, FB BOs into VCPU segment when it isn't", " at 0 (v2)", " - drm/amdgpu/uvd: Place VCPU BO only in VRAM for UVD 4.x and older", " - drm/sysfb: Do not page-align visible size of the framebuffer", " - drm/sysfb: Avoid truncating maximum stride", " - drm/amdgpu/gfx9: Fix Ring and IB test fail after mode2", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/sysfb: Return errno code from drm_sysfb_get_visible_size()", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds", " - drm/amdkfd: Use kvcalloc to allocate arrays", " - drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips", " - drm/i915/hdcp: require monotonically increasing seq_num_v", " - drm/amd/amdgpu: disable ASPM on VI if pcie dpm is disabled", " - drm/amd/pm: fix smu14 power limit range calculation", " - drm/gfx10: Program DB_RING_CONTROL", " - drm/virtio: Don't detach GEM from a non-created context", " - drm/panthor: return error on truncated firmware", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - drm/amd/display: consolidate DCN vblank/flip handling onto", " vupdate_no_lock", " - drm/amd/display: Force PWM backlight on Lenovo Legion 5 15ARH05", " - drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge", " - drm/amd/display: Fix flip-done timeouts on mode1 reset", " - drm/amd/display: Fix missing DCE check in", " dm_gpureset_toggle_interrupts()", " - drm/v3d: Reach the GMP through the hub registers on V3D 7.x", " - media: aspeed: fix missing of_reserved_mem_device_release() on probe", " failure", " - media: cec: seco: unregister adapter on IR probe failure", " - media: cedrus: clean up media device on probe failure", " - media: cedrus: Fix missing cleanup in error path", " - media: imx219: Fix maximum frame length in lines", " - media: iris: Fix use IRQF_NO_AUTOEN when requesting the IRQ", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: nuvoton: npcm-video: fix error handling in npcm_video_init()", " - media: nxp: imx8-isi: Clean up already-initialized pipes on probe", " failure", " - media: nxp: imx8-isi: Fix missing v4l2_subdev_cleanup() in pipe init", " error path", " - media: nxp: imx8-isi: Fix scale factor calculation for hardware rounding", " - media: qcom: camss: Fix RDI streaming for CSID 680", " - media: qcom: camss: Fix RDI streaming for CSID GEN2", " - media: qcom: camss: Fix RDI streaming for CSID GEN3", " - media: rzg2l-cru: Skip ICnMC configuration when ICnSVC is used", " - media: synopsys: hdmirx: Fix HPD lane hold time", " - media: tegra-video: vi: fix invalid u32 return value in format lookup", " - media: v4l2-ctrls-request: add NULL check in", " v4l2_ctrl_request_complete()", " - media: v4l2-subdev: Fail {enable,disable}_streams and s_streaming nicely", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: verisilicon: Export only needed pixels formats", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - media: vpif_capture: fix OF node reference imbalance", " - ALSA: hda/realtek: Fix speakers on Lunnen Ground 14", " - ALSA: hda: codecs: hdmi: disable keep-alive before audio format change", " - wifi: brcmfmac: set F2 blocksize to 256 for BCM43752", " - wifi: ath11k: fix refcount leak in ath11k_ahb_fw_resources_init()", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - platform/loongarch: laptop: Explicitly reset bl_powered state when", " suspend", " - rust_binder: only print failure if error has source", " - rust: time: fix as_micros_ceil() to round correctly for negative Delta", " - rust: allow `clippy::unwrap_or_default` globally", " - objtool/rust: add one more `noreturn` Rust function for Rust 1.99.0", " - LoongArch: Fix address space mismatch in kexec command line lookup", " - LoongArch: Fix oops during single-step debugging", " - LoongArch: Move jump_label_init() before parse_early_param()", " - LoongArch: Retrieve CPU package ID from PPTT when available", " - x86/boot/compressed: Disable jump tables", " - uio_hv_generic: Bind to FCopy device by default", " - serial: sc16is7xx: implement gpio get_direction() callback", " - selftests: ntsync: correct CONFIG_NTSYNC name", " - tracing: Fix context switch counter truncation", " - tracing/eprobe: Fix exact system name matching in", " eprobe_dyn_event_match()", " - tracing/probes: Avoid temporary buffer truncation in", " trace_probe_match_command_args()", " - tracing/probes: Fix potential underflow in LEN_OR_ZERO macro", " - tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err()", " - mptcp: decrement subflows counter on failed passive join", " - mptcp: only set DATA_FIN when a mapping is present", " - mm/kmemleak: fix checksum computation for per-cpu objects", " - mm/huge_memory: set PG_has_hwpoisoned only after new folio head is", " established", " - ceph: fix refcount leak in ceph_readdir()", " - ceph: fix writeback_count leak in write_folio_nounlock()", " - ASoC: fsl: imx-card: Skip sysclk reset for active DAIs in shutdown", " - ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP", " - io_uring/rw: fix missing ERESTARTSYS conversion in read paths", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - net: stmmac: intel: skip SerDes reconfig when rate is unchanged", " - net: pcs: xpcs: fix SGMII state reading", " - proc: Fix broken error paths for namespace links", " - s390/ptff: Export ptff_function_mask[]", " - smb: client: handle STATUS_STOPPED_ON_SYMLINK responses without a", " symlink target", " - ice: use READ_ONCE() to access cached PHC time", " - ovpn: hold peer before scheduling keepalive work", " - vsock/virtio: collapse receive queue under memory pressure", " - watchdog: s32g_wdt: remove incorrect options in watchdog_info struct", " - drm/amd/pm: fix amdgpu_pm_info power display units", " - drm/amd/pm: make pp_features read-only when scpm is enabled", " - drm/amdgpu/jpeg: fix jpeg_v4_0_3_is_idle detection", " - drm/amdgpu/jpeg: fix jpeg_v5_0_1_is_idle detection", " - drm/amdgpu/soc24: reset dGPU if suspend got aborted", " - drm/amdgpu: fix resource leak on ACP reset timeout", " - drm/amd/pm: fix smu13 power limit range calculation", " - drm/amdgpu: fix check in amdgpu_hmm_invalidate_gfx", " - drm/xe/uapi: Reject coh_none PAT index for CPU_ADDR_MIRROR", " - net: qrtr: ns: Raise node count limit to 512", " - drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - xfs: don't replace the wrong part of the cow fork", " - netfilter: nf_tables: remove register tracking infrastructure", " - drm: drop lib from header search path.", " - SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists", " - SUNRPC: Return an error from xdr_buf_to_bvec() on overflow", " - SAUCE: Revert \"mm/sparse-vmemmap: fix vmemmap accounting underflow\"", " - mm/sparse-vmemmap: fix vmemmap accounting underflow", " - mmc: vub300: rename probe error labels", " - net: mana: Optimize irq affinity for low vcpu configs", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - pmdomain: imx93-blk-ctrl: convert to devm_* only", " - rust: allow `suspicious_runtime_symbol_definitions` lint for Rust >=", " 1.98", " - rust: device: avoid trailing ; in printing macros", " - sched_ext: Skip ops.set_weight() for disabled tasks", " - sched_ext: Annotate ksyncs with __rcu in alloc/free_kick_syncs()", " - reset: spacemit: k3: fix USB2 ahb reset", " - wifi: cfg80211: reject empty PMSR peer lists", " - ASoC: amd: acp: Fix linker error with SDCA quirks", " - [Config] Adjust config SND_SOC_ACPI_AMD_SDCA_QUIRKS", " - sched_ext: Enable tick for finite slices on nohz_full", " - Bluetooth: mgmt: Translate HCI reason in Device Disconnected event", " - riscv: Gate FUNCTION_ALIGNMENT_4B on DYNAMIC_FTRACE", " - spi: cadence-quadspi: Fix indirect write timeout when DMA read mode is", " enabled", " - drm/xe: Assign queue name in time for drm_sched_init", " - drm/xe: add WQ_PERCPU to alloc_workqueue users", " - selftests: netconsole: only restore MAC when it changed on resume", " - wifi: ath10k: fix skb leak on incomplete msdu during rx pop", " - wifi: ath12k: Fix low MLO RX throughput on WCN7850", " - iommu/amd: Fix nested domain leak", " - arm_mpam: Fix software reset values of MPAMCFG_PRI", " - arm_mpam: Fix MPAMCFG_MBW_PBM register setting", " - hwmon: Drop unused i2c driver_data", " - hwmon: Use named initializers for arrays of i2c_device_data", " - hwmon: (pmbus/max34440): add support adpm12250", " - hwmon: (pmbus/max34440) block unsupported VIN and IIN limit registers", " - drm/i915/backlight: Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for", " DPCD backlight", " - selftests/net: Fix tun IPv6 test addresses to avoid 6to4 range", " - geneve: fix hint header definition wrt endianness", " - geneve: ensure the skb is writable before fixing its headers", " - accel: ethosu: Handle U85 internal chaining buffer", " - selftests: drv-net: convert so_txtime to drv-net", " - cifs: prevent readdir from changing file size due to stale directory", " metadata", " - wifi: mt76: fix airoha_npu dependency tracking", " - [Config] Fix config dependencies for MT76_NPU", " - drm/panel: ilitek-ili9882t: fix unmet dependency for", " DRM_PANEL_ILITEK_ILI9882T", " - iomap: fix incorrect did_zero setting in iomap_zero_iter()", " - mpls: Set rt->rt_nhn just before returning from mpls_nh_build_multi().", " - LoongArch: BPF: Zero-extend signed ALU32 div/mod results", " - bnge/bng_re: fix ring ID widths", " - pidfs: make pidfs_ino_lock static", " - LoongArch: BPF: Fix memory leak in bpf_jit_free()", " - drm/exynos: fbdev: Remove offset into screen_buffer", " - drm/tegra: fbdev: Remove offset into framebuffer memory", " - drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable", " - drm/amd/pm: re-enable MC access after PrepareMp1ForUnload on SMU V15", " APUs", " - bitmap: add test_zero_nbits()", " - drm/xe: Add compact-PT and addr mask handling for page reclaim", " - drm/amd/display: Restore periodic detection for DCN35", " - drm/amdgpu: Respect placement requirements in amdgpu_gtt_mgr functions", " - drm/amdkfd: Use exclusive bounds for SVM split alignment checks", " - drm/i915/mtl+: Enable PPS before PLL", " - drm/xe/oa: Fix offset alignment for MERT WHITELIST_OA_MERT_MMIO_TRG", " - drm/xe/nvm: fix writable override for CRI", " - drm/amdgpu: Check for multiplication overflow in checkpoint stack size", " - drm/amdkfd: Guard m->cp_hqd_eop_control setting by", " q->eop_ring_buffer_size", " - drm/amdkfd: free MQD managers on DQM init failures", " - drm/amd/display: set MSA MISC1 bit 6 when using VSC SDP for DCE 11.x", " - drm/amdgpu: add the doorbell index input for suspending userq", " - drm/amdgpu: remove deadlocks from amdgpu_userq_pre_reset", " - drm/amd: Create a device link between APU display and XHCI devices", " - drm/pagemap: Clear driver-provided PFNs from migration PFN array", " - mm: add gpu active/reclaim per-node stat counters (v2)", " - drm/ttm: use gpu mm stats to track gpu memory allocations. (v4)", " - drm/ttm: Fix GPU MM stats during pool shrinking", " - drm/ttm/pool: back up at native page order", " - drm/gpusvm: Zero HMM PFNs before scanning ranges", " - media: mali-c55: Add missing of_reserved_mem_device_release()", " - media: mali-c55: Disable pm_runtime on probe error", " - media: mali-c55: Power-off the peripheral in remove()", " - media: qcom: camss: Fix RDI streaming for CSID 340", " - media: rzv2h-ivc: Wait for frame end in stop_streaming", " - media: ti: vpe: Fix fwnode_handle leak in vip_probe_complete()", " - media: ti: vpe: Fix the error code of devm_request_irq()", " - media: uapi: rkisp: Correct name version enum", " - wifi: mt76: restrict NPU/PPE active checks to MMIO devices", " - LoongArch: Fix build errors due to wrong instructions for 32BIT", " - LoongArch: Increase TASK_STRUCT_OFFSET up to 2040 for 32BIT", " - firmware: stratix10-svc: fix teardown order in remove to prevent race", " - firmware: stratix10-svc: handle NO_RESPONSE in async poll", " - tracing: perf: Fix stale head for perf syscall tracing", " - arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates", " - Revert \"arm64: syscall: Ensure saved x0 is kept in-sync with tracer", " updates\"", " - selftests: mptcp: userspace_pm: fix undefined variable port", " - m68k: avoid -Wunused-but-set-parameter in clear_user_page()", " - mm/memory-failure: trace: change memory_failure_event to ras subsystem", " - mm/slub: fix lost local objects when bulk remote free batch fills", " - mm/slab: fix a memory leak due to bootstrapping sheaves twice", " - drm/amdgpu: rework userq fence driver alloc/destroy", " - drm/amdgpu: rework userq fence signal processing", " - drm/amdgpu/gfx11: fix EOP interrupt routing for KQ and userq", " - drm/amdgpu/gfx12: fix EOP interrupt routing for KQ and userq", " - drm/amdgpu/mes11: set doorbell offset for suspending userq", " - selftests: drv-net: add missing kconfig for psp.py", " - mm/sparse-vmemmap: pass @pgmap argument to memory deactivation paths", " - mm/sparse-vmemmap: fix DAX vmemmap accounting with optimization", " - selftests: drv-net: cope with slow env in so_txtime.py test", " - selftests: drv-net: so_txtime: relax variance bounds", " - cifs: fix time_last_write stamp placement in setattr/truncate paths", " - cifs: consolidate time_last_write stamp into _cifsFileInfo_put()", " - Upstream stable to v6.18.41, v6.18.42, v6.18.43, v7.1.6, v7.1.7", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68480", " - x86/bugs: Make Safe-RET robust against interrupt injection", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68105", " - drm/amdgpu: Fix kernel panic during driver load failure", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68109", " - drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68114", " - drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68431", " - ksmbd: validate minimum PDU size for transform requests", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68138", " - net/sched: serialize qdisc_rtab_list against concurrent get/put", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68082", " - libceph: fix two unsafe bare decodes in decode_lockers()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68159", " - libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68163", " - mm/page_vma_mapped: fix device-private PMD handling", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68166", " - userfaultfd: prevent registration of special VMAs", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68170", " - mptcp: fix stale skb->sk reference on subflow close", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68177", " - tracing: Delay module ref count for \"enable_event\" trigger", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68191", " - wifi: ath12k: fix NULL pointer dereference in rhash table destroy", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64586", " - wifi: brcmfmac: drain bus_reset work on device removal", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68208", " - media: ti: vpe: Fix the error code of devm_kzalloc() in", " vip_probe_slice()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68224", " - media: mali-c55: Fix possible ERR_PTR in enable_streams", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68237", " - drm/amdgpu/userq: fix indefinite fence wait during GPU reset", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68240", " - drm/gpusvm: publish dpagemap early to avoid device mapping leak on error", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68242", " - drm/i915/gt: Fix NULL deref on sched_engine alloc failure", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68254", " - drm/i915/vrr: require valid min/max vfreq for VRR", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68436", " - drm/amd/display: use kvzalloc to allocate struct dc", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68447", " - drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68264", " - drm/xe/pt: Reset current_op in xe_pt_update_ops_init()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68265", " - drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68267", " - drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68273", " - drm/amdgpu: Fix context pstate override handling", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68274", " - drm/xe/guc: Fix buffer overflow in steered register list allocation", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68283", " - tracing: Fix use-after-free freeing trigger private data", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68286", " - drop_monitor: perform u64_stats updates under IRQ-disabled section", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68287", " - drop_monitor: fix size calculations for 64-bit attributes", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68288", " - net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68289", " - tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68291", " - idpf: fix max_vport related crash on allocation error during init", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68303", " - drm/vc4: hvs/v3d: Fix null dereference in unbind", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68312", " - cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain", " paths", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68316", " - accel: ethosu: Fix element size accounting for cmd stream validation", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68322", " - rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68440", " - net: txgbe: fix heap overflow when reading module EEPROM", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68323", " - tipc: serialize udp bearer replicast list updates", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68441", " - net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68337", " - bpf: Reject redirect helpers without a bpf_net_context", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68345", " - arm_mpam: guard MBWU state before adding it to garbage", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68347", " - iommu/amd: Fix IRQ unsafe locking in gdom allocation", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68375", " - bnxt_en: Handle partially initialized auxiliary devices", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68382", " - drm/xe/guc: Hold device ref until queue teardown completes", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68383", " - drm/xe/guc: Keep scheduler timeline name alive", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68390", " - Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68404", " - wifi: cfg80211: use wiphy work for socket owner autodisconnect", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64581", " - xfrm: fix sk_dst_cache double-free in xfrm_user_policy()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68093", " - KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision", " after hotplug", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68367", " - usb: gadget: f_tcm: synchronize delayed set_alt with teardown", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68164", " - mm/damon/core: disallow overlapping input ranges for damon_set_regions()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68165", " - mm/damon/core: validate ranges in damon_set_regions()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68095", " - fuse-uring: fix race between registration and connection abortion", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68096", " - audit: fix recursive locking deadlock in audit_dupe_exe()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68147", " - fscrypt: Avoid dynamic allocation in fscrypt_get_devices()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68097", " - ksmbd: validate ACE size against SID sub-authorities", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68098", " - ksmbd: bound DACL dedup walk to copied ACEs", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68099", " - ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68100", " - ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68173", " - ublk: wait on ublk_dev_ready() instead of ub->completion", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68429", " - drm/dp_mst: Handle torn-down topology gracefully in", " drm_dp_mst_topology_queue_probe()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68107", " - drm/amdgpu/vcn4: avoid rereading IB param length", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68108", " - drm/amdgpu/vce: fix integer overflow in image size", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68110", " - drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68112", " - drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68113", " - drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68246", " - drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68116", " - vxlan: mdb: Fix source list corruption on a failed replace", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68118", " - tcp: challenge ACK for non-exact RST in SYN-RECEIVED", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68119", " - tcp: initialize standalone TCP-AO response padding", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68120", " - rtase: Workaround for TX hang caused by hardware packet parsing", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68122", " - ovpn: fix peer refcount leak in TCP error paths", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68124", " - mctp: serial: handle zero-length frames to prevent rx buffer overflow", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68126", " - mac802154: hold an interface reference across the scan worker", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68128", " - ice: reject out-of-range ptype in ice_parser_profile_init", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68130", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68132", " - super: fix emergency thaw deadlock on frozen block devices", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68133", " - ice: fix PTP Call Trace during PTP release", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68134", " - ptp: ptp_s390: Add missing facility check", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68136", " - net: gro: fix double aggregation of flush-marked skbs", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68139", " - net/mlx5e: Use sender devcom for MPV master-up", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68145", " - iomap: fix out-of-bounds bitmap_set() with zero-length range", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68146", " - ftrace: Add global mutex to serialize trace_parser access", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68148", " - fscrypt: Add missing superblock check in find_or_insert_direct_key()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68149", " - fs: preserve ACL_DONT_CACHE state in forget_cached_acl()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68150", " - fs/super: fix emergency thaw double-unlock of s_umount", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68152", " - amt: fix use-after-free in AMT delayed works", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68161", " - sctp: close UDP tunnel sockets during netns teardown", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68162", " - sctp: avoid auth_enable sysctl UAF during netns teardown", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68168", " - afs: Fix afs_edit_dir_remove() to get, not find, block 0", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68169", " - mptcp: pm: userspace: fix use-after-free in get_local_id", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68172", " - arm64: make huge_ptep_get handled unaligned addresses", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68174", " - tracing: Fix union collision of module and refcnt for dynamic events", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68178", " - misc: nsm: pin the module while the device is open", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68179", " - misc: nsm: only unlock nsm_dev on post-lock error paths", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68181", " - mei: bus: access mei_device under device_lock on cleanup", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68434", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64563", " - rhashtable: clear stale iter->p on table restart", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68189", " - Bluetooth: hci_sync: Protect UUID list traversal", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68193", " - wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68194", " - wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68198", " - wifi: ath6kl: fix use-after-free in aggr_reset_state()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68200", " - ALSA: timer: don't re-enter an instance callback that is still running", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68201", " - ALSA: timer: drain a slave's callback before its master detaches it", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68202", " - ALSA: seq: close a re-opened queue timer in the destructor", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68203", " - media: vivid: fix cleanup bugs in vivid_init()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68205", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68206", " - media: v4l2-ctrls: validate HEVC active reference counts", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68207", " - media: ti: vpe: unwind v4l2 device registration on probe error", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68210", " - media: stm32: dcmi: unregister notifier on probe failure", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68211", " - media: stm32-dcmipp: Return queued buffers on start_streaming() failure", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68219", " - media: nxp: imx8-isi: Fix potential out-of-bounds issues", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68220", " - media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and", " pipe", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68221", " - media: nuvoton: npcm-video: fix memory leaks in probe and remove", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68225", " - media: i2c: alvium: fix critical pointer access in alvium_ctrl_init", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68228", " - media: chips-media: wave5: Move src_buf Removal to finish_encode", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68230", " - media: amlogic-c3: Add validations for ae and awb config", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68232", " - drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68445", " - drm/vc4: Prevent shader BO mappings from becoming writable", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68233", " - drm/vc4: Shut down BO cache timer before teardown", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68235", " - drm/amd/display: dce100: skip non-DP stream encoders for DP MST", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68238", " - drm/amdgpu: Release VFCT ACPI table reference", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68239", " - drm/ttm: Account for NULL and handle pages in ttm_pool_backup", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68241", " - drm/i915/mst: limit DP MST ESI service loop", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68245", " - drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68247", " - drm/i915/bios: range check LFP Data Block panel_type2", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68251", " - drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68252", " - drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68253", " - drm/i915/hdcp: check streams[] bounds before overflow", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68255", " - drm/virtio: bound EDID block reads to the response buffer", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68256", " - drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path", " leaks prev_sink reference", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68257", " - drm/amdkfd: fix 32-bit overflow in CWSR total size calculation", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68258", " - drm/amdkfd: Check bounds on CRIU restore queue type and mqd size", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68259", " - drm/amdkfd: Check bounds in allocate_event_notification_slot", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68260", " - drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68261", " - drm/imagination: fix error checking of pvr_vm_context_lookup()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68262", " - drm/imagination: Fix user array stride in pvr_set_uobj_array()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68263", " - drm/imagination: Fix double call to drm_sched_entity_fini()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68266", " - drm/xe: Hold a dma-buf reference for imported BOs", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68268", " - drm/xe: Return error on non-migratable faults requiring devmem", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68269", " - drm/i915/gem: Add missing nospec on parallel submit slot", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68270", " - drm/sysfb: Avoid possible truncation with calculating visible size", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68271", " - drm/nouveau: fix reversed error cleanup order in ucopy functions", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68272", " - drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68275", " - drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68276", " - drm/amdgpu/gfx: fix cleaner shader IB buffer overflow", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68277", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68437", " - drm/imagination: Fit paired fragment job in the correct CCCB", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68278", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68279", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68280", " - drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68281", " - drm/imagination: Count paired job fence as dependency in prepare_job()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68282", " - drm/rockchip: analogix_dp: Add missing error check for", " platform_get_resource()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68290", " - rds: tcp: unregister sysctl before tearing down listen socket", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68292", " - ice: prevent tstamp ring allocation for non-PF VSI types", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68293", " - net/mlx5: Fix MCIA register buffer overflow on 32 dword reads", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68296", " - net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64575", " - bpf: tcp: fix double sock release on batch realloc", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68298", " - drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68302", " - amt: re-read skb header pointers after every pull", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68448", " - ovl: check access to copy_file_range source with src mounter creds", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68306", " - wifi: mt76: mt7996: fix possible NULL-pointer deref in", " mt7996_mcu_sta_bfer_eht()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68307", " - wifi: mt76: mt7925: fix crash in reset link replay", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68308", " - wifi: mt76: mt7996: check pointer returned by", " mt76_connac_get_he_phy_cap()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68439", " - wifi: mt76: mt7925: fix possible NULL-pointer deref in", " mt7925_mcu_bss_he_tlv()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68310", " - wifi: mt76: mt7915: guard HE capability lookups", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68311", " - wifi: mt76: mt7925: guard link STA in decap offload", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64577", " - gtp: check skb_pull_data() return in gtp1u_send_echo_resp()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68314", " - net: mctp i3c: clean up notifier and buses if driver register fails", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68317", " - pds_core: fix auxiliary device add/del races", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68318", " - pds_core: fix use-after-free on workqueue during remove", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68319", " - pds_core: fix deadlock between reset thread and remove", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68321", " - net: txgbe: fix FDIR filter leak on remove", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64574", " - wifi: mac80211: tear down new links on vif update error path", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68329", " - iommu/amd: Wait for completion instead of returning early in", " iommu_completion_wait()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68330", " - net: airoha: Fix DMA direction for NPU mailbox buffer", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68332", " - net: airoha: Fix potential use-after-free in airoha_ppe_deinit()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68334", " - rxrpc: fix io_thread race in rxrpc_wake_up_io_thread()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68336", " - bonding: fix devconf_all NULL dereference when IPv6 is disabled", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68339", " - Bluetooth: btusb: validate Realtek vendor event length", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68341", " - ovpn: fix use after free in unlock_ovpn()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68342", " - ovpn: avoid putting unrelated P2P peer on socket release", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68343", " - smb: client: validate DFS referral PathConsumed", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68346", " - ALSA: hda: cs35l41: validate and free ACPI mute object", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68348", " - ASoC: tas2781: bound firmware description string parsing", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68442", " - btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68356", " - watchdog: airoha: Prevent division by zero when clock frequency is zero", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68358", " - hwmon: (nzxt-kraken3) Stop device IO before calling hid_hw_stop", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68359", " - hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68443", " - hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68362", " - wifi: ath11k: fix NULL pointer dereference in", " ath11k_hal_srng_access_begin", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68371", " - usb: musb: omap2430: Do not put borrowed of_node in probe", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68374", " - usb: core: sysfs: add lock to bos_descriptors_read()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68378", " - dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68379", " - tcp: fix TIME_WAIT socket reference leak on PSP policy failure", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68380", " - accel/amdxdna: Fix use-after-free of mm_struct in job scheduler", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68381", " - ksmbd: pin conn during async oplock break notification", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68384", " - drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68385", " - s390/checksum: Fix csum_partial() without vector facility", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68386", " - bpf, sockmap: Reject unhashed UDP sockets on sockmap update", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68387", " - can: raw: add locking for raw flags bitfield", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68389", " - Bluetooth: hci_qca: Clear memdump state on invalid dump size", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68391", " - Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68392", " - Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68393", " - Bluetooth: hci_sync: extend conn_hash lookup critical sections", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68394", " - Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68396", " - scsi: core: wake eh reliably when using scsi_schedule_eh", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68400", " - firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset", " calculation", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68401", " - firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68407", " - wifi: nl80211: free RNR data on MBSSID mismatch", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68408", " - wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68409", " - wifi: mac80211: defer link RX stats percpu free to RCU", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64570", " - wifi: mac80211: fix fils_discovery double free on alloc failure", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64568", " - wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68412", " - wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64580", " - xfrm6: clear dst.dev on error to avoid double netdev_put in", " xfrm6_fill_dst()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64566", " - xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68415", " - xfrm: clear mode callbacks after failed mode setup", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68416", " - mtd: fix double free and WARN_ON in add_mtd_device() error paths", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68418", " - RDMA/irdma: Prevent user-triggered null deref on QP create", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68419", " - RDMA/irdma: Prevent rereg_mr for non-mem regions", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68420", " - xfrm: reject optional IPTFS templates in outbound policies", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68421", " - sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68426", " - xfrm: fix stale skb->prev after async crypto steals a GSO segment", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68427", " - gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", "", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", "", " * resolute: llvm-21-dev build-depends breaks cross-builds (LP: #2165407)", " - [Packaging] Fix cross-builds", "", " * Resolute Stable Update v6.18.40, v7.1.5 bugs (LP: #2165040)", " - accel/amdxdna: Allow forcing IOVA-based DMA via module parameter", " - SAUCE: bpf: Add missing NULL argument to zap_page_range_single", " - accel/amdxdna: Return ERR_PTR on dma_alloc_noncoherent failure", " - accel/amdxdna: Fix memory leak in amdxdna_iommu_alloc()", "", " * [SRU][HPE] Take Intel platform into account for old microcode checks", " (LP: #2161748)", " - x86/microcode: Refactor platform ID enumeration into a helper", " - x86/cpu: Add platform ID to CPU info structure", " - x86/cpu: Add platform ID to CPU matching structure", " - x86/microcode: Add platform mask to Intel microcode \"old\" list", " - x86/microcode: Do not access MSR_IA32_PLATFORM_ID when running as a", " guest", "", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", "", " * WWAN modem unresponsive after freeze on Dell systems with DW5826e", " (LP: #2163214)", " - platform/x86: dell-dw5826e: Add reset driver for DW5826e", " - platform/x86: dell-dw5826e: fix ACPI _DSM function index and bitmask", " usage", " - [Config] Add CONFIG_DELL_DW5826E_RESET=m", "", " * amdgpu panel self-refresh on dual-gpu laptops causes complete built-in", " panel freeze and severe system instability (LP: #2162904)", " - SAUCE: drm/amdgpu: Do not enter PSR if multiple displays are active", "", " * linux 7.0: dw9719 VCM never binds, disabling all IPU3 cameras (regression,", " fixed upstream) (LP: #2162045)", " - media: dw9719: Add back the I²C device id table", "", " * Fix TAS2783 SoundWire amp resume timeout >5s (LP: #2164967)", " - soundwire: Add a helper function to wait for device initialisation", " - ASoC: tas2783: Use new SoundWire enumeration helper", " - soundwire: Move wait for initialisation helper to header", " - ASoC: codecs: tas2783-sdw: Propagate regcache_sync() errors", " - ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach", "", " * Linux, Ubuntu, 24.04, System hangs for about 10 seconds when unplug", " external monitor cable on non TBT dock (LP: #2160082)", " - SAUCE: drm/i915/tc: Revert forced DP-alt connected workaround", "", " * Speakers not detected on HP systems with TI TAS2783 SoundWire amps", " (LP: #2164504)", " - ASoC: sdw_utils: Add missed component_name strings for TI amps", "", " * [TWL][Desktop] intel_dmc_wait_fw_load() merge to Ubuntu next release", " (LP: #2156316)", " - SAUCE: drm/i915/dmc: fix assert_dmc_loaded WARN during async firmware", " load", "", " * Reboot machine with ext4 configured to data=journal could dump spurious", " call trace (LP: #2164716)", " - ext4: clear stale xarray tags on folios skipped during writeback", "", " * [UBUNTU 22.04] s390/topology: Use zero-based numbering (LP: #2164516)", " - s390/topology: Use zero-based numbering for containing entities", "", " * Ethernet adapter unusable after suspend/resume on Advantech systems with", " Intel I226-V (LP: #2163375)", " - igc: fix netdev not re-attached after resume if interface is down", "", " * ice: fix stale -EBUSY on resume of Intel E810 (LP: #2162803)", " - ice: wait for reset completion in ice_resume()", "", " * idxd: crash-kernel NULL-pointer Oops in `destroy_workqueue()` breaks kdump", " on Intel DSA/IAA systems (LP: #2163062)", " - SAUCE: dmaengine: idxd: Do not call destroy_workqueue with null idxd->wq", " - SAUCE: dmaengine: idxd: fix duplicate memory frees on initialization", " error path.", "", " * [HP][ZBook Power 16 G11] Laptop freezed after upgrading the BIOS", " (LP: #2132119)", " - PCI/ASPM: Avoid L0s for Realtek RTS525A", "", " * Fix noise of audio output on more Dell QCx1255 models after reboot", " (LP: #2163293)", " - ALSA: hda/realtek - Add quirk for Dell Pro QC1255", "", " * Fix no audio input/output device on Dell WCL Slate platform with", " CirrusLogic audio solution (LP: #2160200)", " - ASoC: SDCA: fix the register to ctl value conversion for Q7.8 format", " - ASoC: SOF: ipc4-control: Use local copy of IPC message for sending", "", " * Fix no audio output and mute hotkey not working on HP ZBook 8 G2a", " (LP: #2158858)", " - ALSA: hda/realtek: Add inverted LED quirk for HP ZBook 8 G2a", "", " * Dock ethernet stops working after Thunderbolt dock unplug on Dell systems", " (LP: #2162704)", " - usb: core: port: Deattach Type-C connector on component unbind", "", " * USB-C alt mode dropped with false firmware bug warning on Dell systems", " (LP: #2162695)", " - Revert \"usb: typec: ucsi: Detect and skip duplicate altmodes from buggy", " firmware\"", " - Revert \"usb: typec: ucsi: Add duplicate detection to nvidia registration", " path\"", " - Revert \"usb: typec: ucsi: yoga_c630: Remove redundant duplicate altmode", " handling\"", " - usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware", " - usb: typec: ucsi: Add duplicate detection to nvidia registration path", " - usb: typec: ucsi: yoga_c630: Remove redundant duplicate altmode handling", "", " * Resolute update: upstream stable patchset 2026-08-20 (LP: #2164666)", " - crypto: algif_skcipher - force synchronous processing", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " - [Config] Remove unused CRYPTO_DEV_SUN4I_SS_PRNG", " - media: uvcvideo: Fix deadlock if uvc_status_stop is called from", " async_ctrl.work", " - bpf: Clear delta when clearing reg id for non-{add,sub} ops", " - selftests/bpf: Add tests for delta tracking when src_reg == dst_reg", " - selftests/bpf: Add tests for stale delta leaking through id reassignment", " - ALSA: hda/realtek: Add quirk for TongFang X6xx45xU", " - ALSA: hda: conexant: Remove mic bias threshold override", " - ALSA: hda: Fix cached processing coefficient verbs", " - ALSA: hda/realtek: Fix speakers on Legion Pro 7 16ARX8H with codec SSID", " 17aa:38a7", " - media: uvcvideo: Use hw timestaming if the clock buffer is full", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - media: uvcvideo: Fix dev_sof filtering in hw timestamp", " - media: uvcvideo: Do not add clock samples with small sof delta", " - media: uvcvideo: Relax the constrains for interpolating the hw clock", " - media: uvcvideo: Fix sequence number when no EOF", " - dt-bindings: media: sun4i-a10-video-engine: Add interconnect properties", " - dt-bindings: power: imx93: Add MIPI PHY power domain", " - serial: msm: Disable DMA for kernel console UART", " - serial: max310x: implement gpio_chip::get_direction()", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc", " - rxrpc: Fix socket notification race", " - rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)", " - rxrpc: Fix potential infinite loop in rxrpc_recvmsg()", " - rxrpc: Fix rxrpc_rotate_tx_rotate() to check there's something to rotate", " - rxrpc: Fix oob challenge leak in cleanup after notification failure", " - rxrpc: Fix ACKALL packet handling", " - rxrpc: Fix the reception of a reply packet before data transmission", " - rxrpc: Fix leak of connection from OOB challenge", " - afs: fix NULL pointer dereference in afs_get_tree()", " - afs: handle CB.InitCallBackState3 requests without a server record", " - afs: Fix uncancelled rxrpc OOB message handler", " - fbcon: fix NULL pointer dereference for a console without vc_data", " - fbcon: Use correct type for vc_resize() return value", " - openrisc: mm: Fix section mismatch between map_page and __set_fixmap", " - clocksource/drivers/sun5i: Handle error returns from", " devm_reset_control_get_optional_exclusive()", " - accel/amdxdna: Fix leak when pinning ubuf pages", " - drm/rockchip: dw_dp: Switch to drmm_kzalloc()", " - drm/rockchip: dw_dp: Fix null-ptr-deref in dw_dp_remove()", " - drm/rockchip: Test for imported buffers with drm_gem_is_imported()", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - drm/gpusvm: Reject VMAs with VM_IO or VM_PFNMAP when creating SVM ranges", " - drm/gpuvm: Do not prepare NULL objects", " - drm/amdgpu: fix integer overflow in amdgpu_gem_align_pitch()", " - drm/radeon: fix integer overflow in radeon_align_pitch()", " - drm/radeon: fix memory leak in radeon_ring_restore() on lock failure", " - libbpf: Report error when a negative kprobe offset is specified", " - selftests/bpf: Fix off-by-one in bpf_cpumask_populate related selftest", " - dt-bindings: timer: Remove sifive,fine-ctr-bits property", " - drm/amd/pm: remove trailing semicolon from AMDGPU_PM_POLICY_ATTR macro", " - selftests/bpf: Use local type for flow_offload_tuple_rhash in", " xdp_flowtable", " - selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern", " - Documentation: proc: fix section numbering in table of contents", " - arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Cobra", " - arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S", " - arm64: dts: qcom: ipq5424: Fix USB simple_bus_reg warnings", " - arm64: dts: qcom: sc8180x: Fix phy simple_bus_reg warning", " - arm64: dts: qcom: sdm845-mezzanine: Fix camss ports unit_address_vs_reg", " warning", " - wifi: cfg80211: fix grammar in MLO group key error message", " - arm64: tegra: Fix Tegra234 MGBE PTP clock", " - dt-bindings: pinctrl: nvidia,tegra234: Add missing required block", " - drm/amdkfd: Validate CRIU-restored IDs before idr_alloc", " - driver core: use READ_ONCE() for dev->driver in dev_has_sync_state()", " - wifi: rtw89: fix wrong pci_get_drvdata type in AER handlers", " - wifi: rtw88: fix wrong pci_get_drvdata type in AER handlers", " - wifi: rtw89: Correct data type for scan index to avoid infinite loop", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " - wifi: rtw89: add bounds check on firmware mac_id in link lookup", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - soc: xilinx: Shutdown and free rx mailbox channel", " - pinctrl: mediatek: eint: Drop base from mtk_eint_chip_write_mask()", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - Documentation/rv: Replace stale website link", " - watchdog: sp5100_tco: Use EFCH MMIO for newer Hygon FCH", " - watchdog: sama5d4_wdt: Fix WDDIS detection on SAM9X60 and SAMA7G5", " - watchdog: sprd_wdt: Remove redundant sprd_wdt_disable() on register", " failure", " - media: cedrus: Fix failure to clean up hardware on probe failure", " - media: v4l2-common: Add YUV24 format info", " - memory: tegra: Wire up system sleep PM ops", " - crypto: qat - fix heartbeat error injection", " - lib/vsprintf: Fix to check field_width and precision", " - dts: spacemit: set console baud rate on bpif3", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - dt-bindings: vendor-prefixes: Add Displaytech Ltd.", " - drm/gpuvm: take refcount on DRM device", " - drm/panel: Clean up S6E3HA2 config dependencies and fill help text", " - ARM: dts: rockchip: Add #{address,size}-cells to Chromium-based", " /firmware", " - arm64: dts: rockchip: Add #{address,size}-cells to Chromium-based", " /firmware", " - arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc", " - arm64: dts: imx8x-colibri: Correct SODIMM PAD settings", " - Revert \"arm64: dts: imx8mm-kontron: Add support for reading SD_VSEL", " signal\"", " - Revert \"arm64: dts: imx8mp-kontron: Add support for reading SD_VSEL", " signal\"", " - drm: renesas: rz-du: mipi_dsi: Fix return path on error", " - alarmtimer: Remove stale return description from alarm_handle_timer()", " - OPP: Fix race between OPP addition and lookup", " - crypto: ccp - Reverse the cleanup order in psp_dev_destroy()", " - crypto: ccp - Fix snp_filter_reserved_mem_regions() off-by-one", " - crypto: atmel-sha204a - fix blocking and non-blocking rng logic", " - crypto: ecrdsa - fix unknown OID check in ecrdsa_param_curve", " - crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents", " - ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD", " - nilfs2: fix backing_dev_info reference leak", " - media: qcom: camss: vfe: fix PIX subdev naming on VFE lite", " - media: iris: scale MMCX power domain on SM8250", " - media: venus: scale MMCX power domain on SM8250", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - soc: mediatek: mtk-mmsys: Restore MT8167 routing masks lost during merge", " - bpf: fix crash in bpf_[set|remove]_dentry_xattr for negative dentries", " - uaccess: fix ignored_trailing logic in copy_struct_to_user()", " - arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to", " host", " - rust: alloc: fix `Vec::extend_with` SAFETY comment", " - clk: scmi: Fix clock rate rounding", " - arm64: dts: qcom: kodiak: Fix ICE reg size", " - arm64: dts: qcom: sm8450: Fix ICE reg size", " - drm/hisilicon/hibmc: add updating link cap in DP detect()", " - drm/hisilicon/hibmc: fix no showing when no connectors connected", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - drm/hisilicon/hibmc: use clock to look up the PLL value", " - evm: terminate and bound the evm_xattrs read buffer", " - thermal: hwmon: Fix critical temperature attribute removal", " - clk: scpi: Unregister child clock providers on remove", " - net/sched: sch_hfsc: annotate data-races in hfsc_dump_class_stats()", " - scsi: hisi_sas: Add slave_destroy interface for v3 hw", " - crypto: ccp - Treat zero-length cert chain as query for blob lengths", " - spi: hisi-kunpeng: Use dev_err_probe() for host registration failure", " - net/sched: sch_htb: do not change sch->flags in htb_dump()", " - net/sched: sch_htb: annotate data-races (I)", " - IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " - RDMA/hns: Initialize seqfile before creating file", " - drm/syncobj: Fix memory leak in drm_syncobj_find_fence()", " - selftests/bpf: Reject unsupported -k option in vmtest.sh", " - selftests/bpf: Fix test for refinement of single-value tnum", " - iommu/arm-smmu-qcom: Fix fastrpc compatible string in ACTLR client match", " table", " - selftests/mm: Fix resv_sz when parsing arm64 signal frame", " - firmware: arm_ffa: Honor partition info descriptor size", " - arm64: dts: imx8dxl-evk: Remove unnecessary PCIe EP properties", " - arm64: dts: imx8qxp-mek: Remove unnecessary PCIe EP vpcie-supply", " - arm64: dts: imx95-19x19-evk: Fix PCIe EP vpcie-supply", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - media: atomisp: gc2235: fix UAF and memory leak", " - staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy()", " - riscv: dts: spacemit: set console baud rate on Milk-V Jupiter", " - firmware: smccc: Fix Arm SMCCC SOC_ID name call", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - bitops: use common function parameter names", " - regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions", " - tools/nolibc: getopt: Fix potential out of bounds access", " - nilfs2: Fix return in nilfs_mkdir", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - media: rockchip: rga: fix too small buffer size", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - arm64: dts: qcom: lemans: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: monaco: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sc7180: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: kodiak: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8550: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8750: Add power-domain and iface clk for ice node", " - tracing: Bound synthetic-field strings with seq_buf", " - arm64: dts: qcom: lemans: Add eDP ref clock for eDP PHYs", " - writeback: drop now-unnecessary rcu_barrier() in", " cgroup_writeback_umount()", " - kernfs: fix suspicious RCU usage in kernfs_put()", " - device property: fix fwnode reference leak in", " fwnode_graph_get_endpoint_by_id()", " - driver core: Use mod_delayed_work to prevent lost deferred probe work", " - Revert \"treewide: Fix probing of devices in DT overlays\"", " - of: dynamic: Fix overlayed devices not probing because of fw_devlink", " - crypto: eip93 - fix reset ring register definition", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - RDMA/mana_ib: Use ib_get_eth_speed for reporting port speed", " - bus: sunxi-rsb: Always check register address validity", " - pinctrl: spacemit: fix NULL check in spacemit_pin_set_config", " - RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs", " - RDMA/rxe: Fix a use-after-free problem in rxe_mmap", " - IB/mlx4: Fix refcount leak in add_port() error path", " - RDMA/hns: Fix warning in poll cq direct mode", " - RDMA/hns: Fix log flood after cmd_mbox failure", " - RDMA/counter: Fix incorrect port index in rdma_counter_init() error", " cleanup", " - pinctrl: meson: amlogic-a4: fix gpio output glitch", " - PM: sleep: Use complete() in device_pm_sleep_init()", " - MIPS: Fix big-endian stack argument fetching in o32 wrapper", " - MIPS: DEC: Remove do_IRQ() call indirection", " - mips: ralink: mt7621: add missing __iomem", " - mips: n64: add __iomem for writel call", " - driver core: Fix missing jiffies conversion in", " deferred_probe_extend_timeout()", " - driver core: Guard deferred probe timeout extension with", " delayed_work_pending()", " - mtd: spi-nor: debugfs: Fix the flags list", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - ALSA: xen-front: Reset event channel state on stream clear", " - ALSA: xen-front: Connect event channel after stream prepare", " - ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data", " - ALSA: seq: midi: Serialize output teardown with event_input", " - selftests: Fix Makefile target for nsfs", " - pinctrl: nuvoton: ma35d1: fix MFP register offset and pin table", " - pinctrl: cs42l43: Fix leaked pm reference on error path", " - pinctrl: cs42l43: Fix polarity on debounce", " - init/initramfs_test: wait_for_initramfs() before running", " - nvmet-tcp: fix page fragment cache leak in error path", " - nvmet-tcp: check return value of nvmet_tcp_set_queue_sock", " - nvme-pci: fix out-of-bounds access in nvme_setup_descriptor_pools", " - workqueue: drop spurious '*' from print_worker_info() fn declaration", " - ipv6: guard against possible NULL deref in __in6_dev_stats_get()", " - net/sched: cls_bpf: prevent unbounded recursion in offload rollback", " - iommu/amd: Fix premature break in init_iommu_one()", " - rtla/actions: Restore continue flag in actions_perform()", " - drm/tegra: gr2d/gr3d: Initialize address register map before HOST1X", " client is registered", " - drm/tegra: gr2d/gr3d: Contain PM in the gr*d_probe/gr*d_remove", " - gpu: host1x: Allow entries in BO caches to be freed", " - drm/tegra: dc: Fix device node reference leak in tegra_dc_has_output()", " - gpu: host1x: Fix iommu_map_sgtable() return value check", " - drm/tegra: Fix iommu_map_sgtable() return value check", " - drm/nouveau/bios: specify correct display fuse register for Ampere and", " Ada", " - libbpf: Harden parse_vma_segs() path parsing", " - bpftool: Fix typo in struct_ops map FD generation for light skeleton", " - libbpf: Fix UAF in strset__add_str()", " - ARM: tegra: Add #{address,size}-cells to Chromium-based /firmware", " - arm64: tegra: Add #{address,size}-cells to Chromium-based /firmware", " - dax/kmem: account for partial discontiguous resource upon removal", " - rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc()", " - ocfs2: don't BUG_ON an invalid journal dinode", " - ocfs2: kill osb->system_file_mutex lock", " - crypto: hisilicon/qm - disable error report before flr", " - crypto: inside-secure/eip93 - Add check for devm_request_threaded_irq", " - crypto: tegra - Fix dma_free_coherent size error", " - crypto: tegra - Return ENOMEM when input buffer allocation fails for ccm", " - sched/deadline: Reject debugfs dl_server writes for offline CPUs", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/igen6: Fix call trace due to missing release()", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - arm64: dts: st: Fix SAI addresses on stm32mp251", " - RDMA/umem: Add ib_umem_is_contiguous() stub for", " !CONFIG_INFINIBAND_USER_MEM", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " - RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path", " - Revert \"media: venus: hfi_platform: Correct supported codecs for sc7280\"", " - media: qcom: venus: drop extra padding in NV12 raw size calculation", " - media: qcom: venus: relax encoder frame/blur dimension steps on v4", " - media: qcom: venus: relax encoder frame/blur step size on v6", " - amba: use generic driver_override infrastructure", " - cdx: use generic driver_override infrastructure", " - Drivers: hv: vmbus: use generic driver_override infrastructure", " - rpmsg: use generic driver_override infrastructure", " - raid1: fix nr_pending leak in REQ_ATOMIC bad-block error path", " - bpf: fix BPF_PROG_QUERY OOB write and cgroup backward compat", " - selftests/bpf: add verification for BPF_PROG_QUERY attr size boundaries", " - libbpf: Skip hash computation when loader generation failed", " - libbpf: Skip endianness swap when loader generation failed", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - spi: atmel: fix DMA channel and bounce buffer leaks", " - ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble", " - NFSD: Fix delegation reference leak in nfsd4_revoke_states", " - ARM: imx3: Fix CCM node reference leak", " - HID: wiimote: Fix table layout and whitespace errors", " - wifi: ath12k: fix incorrect HT/VHT/HE/EHT MCS reporting in monitor mode", " - wifi: ath12k: fix NULL deref in change_sta_links for unready link", " - ata: libata: Fix ata_exec_internal()", " - ARM: imx31: Fix IIM mapping leak in revision check", " - x86/cpu: Keep the PROCESSOR_SELECT menu together", " - nvdimm/btt: Handle preemption in BTT lane acquisition", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - bpf: Reject exclusive maps as inner maps in map-in-map", " - libbpf: Reject non-exclusive metadata maps in the signed loader", " - libbpf: Skip initial_value override on signed loaders", " - libbpf: Skip max_entries override on signed loaders", " - scsi: pm8001: Fix error code in non_fatal_log_show()", " - scsi: ufs: Fix wrong value printed in unexpected UPIU response case", " - bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs", " - mm/fake-numa: fix under-allocation detection in uniform split", " - ext2: fix ignored return value of generic_write_sync()", " - sched: restore timer_slack_ns when resetting RT policy on fork", " - driver core: Use system_percpu_wq instead of system_wq", " - bpf: Reject exclusive maps for bpf_map_elem iterators", " - tick/sched: Fix TOCTOU in nohz idle time fetch", " - lib/test_meminit: use && for bools", " - riscv: dts: sophgo: sg2044: use hex for CPU unit address", " - riscv: dts: sophgo: sg2042: use hex for CPU unit address", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " - lockdep/selftests: Restore migrate_disable() state on PREEMPT_RT", " - lockdep/selftests: Restore sched_rt_mutex state on PREEMPT_RT", " - ext4: fix fast commit wait/wake bit mapping on 64-bit", " - drm/amdgpu: set sub_block_index for mca ras sub-blocks", " - bpftool: Use libbpf error code for flow dissector query", " - vhost: fix vhost_get_avail_idx for a non empty ring", " - iommu/vt-d: Fix RB-tree corruption in probe error path", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems", " - perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains", " - xfrm: fix NAT-related field inheritance in SA migration", " - cxl/fwctl: Fix __fortify_panic", " - drm/amdkfd: always resume_all after suspend_all", " - of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array()", " fails", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " - lib: kunit_iov_iter: repeatedly call alloc_pages_bulk()", " - ocfs2: fix buffer head management in ocfs2_read_blocks()", " - ocfs2: reject FITRIM ranges shorter than a cluster", " - ocfs2/dlm: require a ref for locking_state debugfs open", " - ocfs2: fix race between ocfs2_control_install_private() and", " ocfs2_control_release()", " - netfilter: nfnetlink_osf: fix mss parsing on big-endian architectures", " - netfilter: nfnetlink_cthelper: use {READ,WRITE}_ONCE for accessing", " helper flags", " - netfilter: synproxy: drop packets if timestamp adjustment fails", " - netfilter: synproxy: adjust duplicate timestamp options", " - netfilter: synproxy: fix unaligned memory access in timestamp adjustment", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - ALSA: usb-audio: qcom: Initialize offload control return value", " - x86/cpu: Remove obsolete aperfmperf_get_khz() declaration", " - netfilter: conntrack: revert ct extension genid infrastructure", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - RDMA/hfi1: Open-code rvt_set_ibdev_name()", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - ALSA: hda: fix Kconfig dependency of HD Audio PCI", " - RDMA/irdma: Fix OOB read during CQ MR registration", " - RDMA/irdma: Initialize iwmr->access during MR registration", " - arm64: dts: imx8mp-kontron: Reduce EERAM SPI clock frequency", " - arm64: dts: imx95: Correct PCIe outbound address space configuration", " - arm64: dts: lx2162a-clearfog: use rev2 SoC dtsi", " - arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as", " well", " - arm64: dts: imx8mp-kontron: Fix GPIO for display power switch", " - bpf: Clear rb node linkage when freeing bpf_rb_root", " - bpf: Check tail zero of bpf_map_info", " - bpf: Check tail zero of bpf_prog_info", " - bpf: Update transport_header when encapsulating UDP tunnel in lwt", " - wifi: wcn36xx: fix heap overflow from oversized firmware HAL response", " - wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO", " indication", " - wifi: wcn36xx: fix OOB read from short trigger BA firmware response", " - ALSA: seq: Fix partial userptr event expansion", " - riscv: cpu_ops: Change return value type of cpu_is_stopped() to bool", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Clear variable event pointer on read", " - bpf: Fix NMI/tracepoint re-entry deadlock on lru locks", " - kunit:tool: Don't write to stdout when it should be disabled", " - powerpc/8xx: implement get_direction() in cpm1", " - bpf: Fix NULL pointer dereference in bpf_task_from_vpid()", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - thermal: testing: reject missing command arguments", " - btrfs: don't force DIO writes to be serialized", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - IB/mlx5: Remove unused mkc bits in mlx5r_umr_update_mr_page_shift()", " - IB/mlx5: Pull the pdn out of the depths of the umr machinery", " - IB/mlx5: Don't mangle the mr->pd inside the rereg callback", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - ASoC: amd: acp-sdw-legacy: Bound DAI link iteration", " - ASoC: amd: acp-sdw-sof: Bound DAI link iteration", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " - configfs: fix lockless traversals of ->s_children", " - watchdog: unregister PM notifier on watchdog unregister", " - pinctrl: qcom: Fix resolving register base address from device node", " - scsi: target: Fix hexadecimal CHAP_I handling", " - scsi: target: Remove tcm_loop target reset handling", " - pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset of pins", " 34-39", " - pinctrl: mediatek: mt8167: Fix Schmitt trigger register offset of pins", " 34-39", " - vmalloc: fix NULL pointer dereference in is_vm_area_hugepages()", " - hwspinlock: qcom: avoid uninitialized struct members", " - sched/fair: Fix cpu_util runnable_avg arithmetic", " - ARM: configs: Drop duplicated CONFIG_EXT4_FS", " - wifi: mt76: mt7925: clean up DMA on probe failure", " - wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link", " - wifi: mt76: mt7996: add missing max_remain_on_channel_duration", " - wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_links", " - wifi: mt76: mt7925: keep TX BA state in the primary WCID", " - wifi: mt76: mt792x: skip MLD header rewrite for 802.3 encap TX", " - wifi: mt76: mt7925: validate skb length in testmode query", " - wifi: mt76: mt7996: Fix possible token leak in mt7996_tx_prepare_skb()", " - wifi: mt76: mt7996: Fix possible NULL pointer dereference in", " mt7996_mac_write_txwi_80211()", " - wifi: mt76: mt7996: fix reading zeroed info->control.flags after", " mt76_tx_status_skb_add()", " - wifi: mt76: mt7996: limit work in set_bitrate_mask", " - wifi: mt76: fix argument to ieee80211_is_first_frag()", " - wifi: mt76: mt7915: fix potential tx_retries underflow", " - wifi: mt76: mt7921: fix potential tx_retries underflow", " - wifi: mt76: mt7925: fix potential tx_retries underflow", " - wifi: mt76: mt7996: fix potential tx_retries underflow", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " - ALSA: aloop: Drop superfluous break", " - gpio: mt7621: fix interrupt banks mapping on gpio chips", " - wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is", " reported", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " - vfs: add FS_USERNS_DELEGATABLE flag and set it for NFS", " - hwmon: (it87) Clamp negative values to zero in set_fan()", " - btrfs: zoned: don't account data relocation space-info in statfs free", " space", " - Revert \"btrfs: fix the file offset calculation inside", " btrfs_decompress_buf2page()\"", " - btrfs: zoned: always set max_active_zones for zoned devices", " - btrfs: annotate lockless read of defrag_bytes in should_nocow()", " - btrfs: fix deadlock cloning inline extent when using flushoncommit", " - igc: skip RX timestamp header for frame preemption verification", " - ASoC: sma1307: Fix uevent string leaks in fault worker", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - NFSD: Handle layout stid in nfsd4_drop_revoked_stid()", " - spi: meson-spifc: fix runtime PM leak on remove", " - ASoC: codecs: aw88261: fix incorrect masks for boost regs", " - vduse: hold vduse_lock across IDR lookup in open path", " - vhost/vdpa: validate virtqueue index in mmap and fault paths", " - virtio: rtc: tear down old virtqueues before restore", " - virtio_console: read size from config space during device init", " - vduse: Requeue failed read to send_list head", " - tools/virtio: check mmap return value in vringh_test", " - vdpa/octeon_ep: Fix PF->VF mailbox data address calculation", " - vdpa/octeon_ep: fix IRQ-to-ring mapping in interrupt handler", " - ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()", " - ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails", " - ext4: fix ERR_PTR(0) in ext4_mkdir()", " - tools: missed broadcast_neigh if_link uapi header", " - netlink: specs: rt-link: missed broadcast-neigh", " - bonding: 3ad: add lacp_strict configuration knob", " - bonding: 3ad: fix carrier when no usable slaves", " - bonding: 3ad: fix mux port state on oper down", " - ext4: fix kernel BUG in ext4_write_inline_data_end", " - selftests/bpf: Fix bpf_iter/task_vma test", " - cxl/test: Fix integer overflow in mock LSA bounds checks", " - cxl/test: Zero out LSA backing memory to avoid leaking to user", " - of: cpu: add check in __of_find_n_match_cpu_property()", " - vfio/qat: fix f_pos race in qat_vf_resume_write()", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " - pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag", " - pinctrl: airoha: an7581: add missed gpio32 pin group", " - pinctrl: airoha: an7581: fix misprint in gpio19 pinconf", " - arm64: dts: allwinner: a523: Add missing GPIO interrupt", " - ASoC: cs35l56: Fix possible uninitialized value in", " cs35l56_spi_system_reset()", " - s390/process: Fix kernel thread function pointer type", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for", " non-serdev device", " - Bluetooth: eir: Fix stack OOB write when prepending the Flags AD", " - Bluetooth: hci_event: fix simultaneous discovery stuck in FINDING", " - Bluetooth: hci_core: Fix UAF in hci_unregister_dev()", " - Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path", " - Bluetooth: hci: validate codec capability element length", " - Bluetooth: vhci: validate devcoredump state before side effects", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove DCT restrack tracking", " - RDMA/mlx5: Remove raw RSS QP restrack tracking", " - RDMA/mlx5: Fix undefined shift of user RQ WQE size", " - RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one", " - ASoC: SOF: Intel: hda-sdw-bpt: select SND_SOF_SOF_HDA_SDW_BPT properly", " - ASoC: codecs: hdac_hdmi: Validate written enum value", " - ASoC: fsl: fsl_audmix: Validate written enum values", " - ASoC: tegra: tegra210_ahub: Validate written enum value", " - net: dsa: qca8k: fix led devicename when using external mdio bus", " - net/sched: cls_flow: Dont expose folded kernel pointers", " - net: fib_rules: Don't dump dying fib_rule in fib_rules_dump().", " - bridge: cfm: reject invalid CCM interval at configuration time", " - net: pfcp: allocate per-cpu tstats for PFCP netdevs", " - net/sched: sch_hfsc: Don't make class passive twice", " - tipc: require net admin for TIPCv2 netlink mutators", " - tipc: prevent snt_unacked underflow on CONN_ACK", " - tipc: reject inverted service ranges from peer bindings", " - cxl/test: Unregister cxl_acpi in cxl_test_init() error path", " - cxl/test: Add check after kzalloc() memory in alloc_mock_res()", " - crypto: marvell/octeontx - fix DMA cleanup using wrong loop index", " - crypto: cavium/cpt - fix DMA cleanup using wrong loop index", " - crypto: rng - Free default RNG on module exit", " - ALSA: usb-audio: qcom: Guard sideband endpoint removal", " - ALSA: seq: Fix kernel heap address leak in bounce_error_event()", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " - iommu: Avoid copying the user array twice in the full-array copy helper", " - ASoC: adau1372: Clear PLL_EN on failed PLL lock without reset GPIO", " - power: supply: core: fix supplied_from allocations", " - handshake: Require admin permission for DONE command", " - virtio_net: do not allow tunnel csum offload for non GSO packets", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net/sched: sch_dualpi2: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net: mana: initialize gdma queue id to INVALID_QUEUE_ID", " - net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check", " - net: watchdog: fix refcount tracking races", " - net: ethernet: mtk_wed: fix loading WO firmware for MT7986", " - net/sched: sch_dualpi2: Add missing module alias", " - bpf: Run generic devmap egress prog on private skb", " - net/mlx5: Check max_macs devlink param value against max capability", " - bpf: Fix setting retval to -EPERM for cgroup hooks not returning errno", " - octeontx2-af: npc: Fix size of entry2cntr_map", " - net: ethernet: mtk_wed: debugfs: correct index in wed_amsdu_show()", " - net: wwan: t7xx: check skb_clone in control TX", " - dpll: fix stale iteration in dpll_pin_on_pin_unregister()", " - dpll: send delete notification before unregister in on-pin rollback", " - dpll: emit per-dpll delete notifications in dpll_pin_on_pin_unregister()", " - dpll: guard sync-pair removal on full pin unregister", " - dpll: balance create/delete notifications in __dpll_pin_(un)register", " - landlock: Fix unmarked concurrent access to socket family", " - net: bcmgenet: Use weighted round-robin TX DMA arbitration", " - net: airoha: Fix register index for Tx-fwd counter configuration", " - net: airoha: Fix debugfs new-tuple display for IPv4 ROUTE entries", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " - ALSA: seq: oss: Serialize readq reset state with q->lock", " - ALSA: seq: avoid stale FIFO cells during resize", " - netfilter: nf_conncount: callers must hold rcu read lock", " - ALSA: core: Fix unintuitive behavior of snd_power_ref_and_wait()", " - cifs: remove all cifs files before kill super", " - smb/client: always return a value for FS_IOC_GETFLAGS", " - selftests/bpf: Fix typo in verify_umulti_link_info", " - selftests/bpf: Initialize operation name before use", " - bpf: Fix bpf_get/setsockopt to tos for ipv4-mapped ipv6 socket", " - udf: fix nls leak on udf_fill_super() failure", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " - net: remove addr_len argument of recvmsg() handlers", " - sockmap: Fix use-after-free in udp_bpf_recvmsg()", " - bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check", " - MIPS: mm: Fix out-of-bounds write in maar_res_walk()", " - powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del", " - powerpc/powernv: fix preempt count leak in", " pnv_kexec_wait_secondaries_down", " - powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus", " - KEYS: Use acquire when reading state in keyring search", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " - net: airoha: Fix always-true condition in PPE1 queue reservation loop", " - net: ethernet: oa_tc6: Remove FCS size in RX frame", " - ionic: Fix check in ionic_get_link_ext_stats", " - RDMA/bnxt_re: Free SRQ toggle page after firmware teardown", " - RDMA/bnxt_re: Avoid displaying the kernel pointer", " - RDMA/bnxt_re: Fail DBR related page allocation UAPIs if the feature is", " disabled", " - ksmbd: fix use-after-free in same_client_has_lease()", " - mfd: rsmu: Fix page register setup", " - mfd: cs42l43: Sanity check firmware size", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - 9p: avoid returning ERR_PTR(0) from mkdir operations", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: expand top-of-file overview / locking doc", " - eventpoll: rename attach_epitem() to ep_attach_file()", " - eventpoll: split ep_insert() into alloc + register stages", " - eventpoll: extract ep_deliver_event() from ep_send_events()", " - eventpoll: wrap EP_UNACTIVE_PTR in typed sentinel helpers", " - eventpoll: rename epi->next and txlist for clarity", " - eventpoll: Fix epoll_wait() report false negative", " - gpiolib: acpi: Only trigger ActiveBoth interrupts on boot", " - i3c: master: svc: Fix missed IBI after false SLVSTART on NPCM845", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " - perf debuginfo: Fix libdw API contract violations", " - coresight: cti: Fix DT filter signals silently ignored", " - soundwire: don't program SDW_SCP_BUSCLOCK_SCALE on a unattached", " Peripheral", " - soundwire: fix bug in sdw_add_element_group_count found by syzkaller", " - coresight: ete: Always save state on power down", " - coresight: etm4x: Correct TRCVMIDCCTLR1 save and restore", " - PCI/ASPM: Don't reconfigure ASPM entering low-power state", " - PCI: Introduce named defines for PCI ROM", " - PCI: Check ROM header and data structure addr before accessing", " - x86/platform/olpc: xo15: Drop wakeup source on driver removal", " - platform/x86: xo15-ebook: Fix wakeup source and GPE handling", " - perf sched: Add missing mmap2 handler in timehist", " - PCI: loongson: Do not ignore downstream devices on external bridges", " - rust: alloc: fix assert in `Vec::reserve` doc test", " - bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker()", " - coresight: fix missing error code when trace ID is invalid", " - clk: qcom: cmnpll: Account for reference clock divider", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - perf pmu: Skip test on Arm64 when #slots is zero", " - clk: at91: sam9x7: Fix gmac_gclk clock definition", " - soundwire: intel_ace2x: release bpt_stream when close it", " - coresight: Fix source not disabled on idr_alloc_u32 failure", " - mailbox: mpfs: fix check for syscon presence in mpfs_mbox_inbox_isr()", " - mailbox: mtk-adsp: fix UAF during device teardown", " - PCI: dwc: Fix signedness bug in fault injection test code", " - perf build-id: Fix off-by-one bug when printing kernel/module build-id", " - staging: most: video: avoid double free on video register failure", " - usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control()", " - usb: host: max3421: Reject hub port requests for non-existent ports", " - perf test amd ibs: Fix incorrect kernel version check", " - gpib: Fix inappropriate ioctl error return", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - gpib: fix double decrement of descriptor_busy in command_ioctl()", " - clk: renesas: rzg2l: Rename iterator in for_each_mod_clock() to avoid", " shadowing", " - powerpc tools perf: Initialize error code in auxtrace_record_init", " function", " - PCI: qcom: Disable ASPM L0s for SA8775P", " - perf header: Sanity check HEADER_EVENT_DESC attr.size before swap", " - iio: light: si1133: reset counter to prevent race condition", " - iio: light: si1133: prevent race condition on timeout", " - iio: magnetometer: ak8975: fix potential kernel stack memory leak", " - iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling", " - iio: accel: mma8452: handle I2C read error(s) in mma8452_read()", " - iio: tcs3472: power down chip on probe failure", " - clk: at91: keep securam node alive while mapping it", " - HID: logitech-hidpp: remove excess kernel-doc member in", " hidpp_scroll_counter", " - fs/ntfs3: add bounds check to run_get_highest_vcn()", " - fs/ntfs3: fix mount failure on 64K page-size kernels", " - drm/amd/display: Add missing kdoc for ALLM parameters", " - thunderbolt: debugfs: Fix margining error counter buffer leak", " - dmaengine: imx-sdma: Refine spba bus searching in probe", " - dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional", " - perf: Fix off-by-one stack buffer overflow in kallsyms__parse()", " - perf annotate: Fix crashes on empty annotate windows", " - perf tools: Guard test_bit from out-of-bounds sample CPU", " - perf sched: Fix thread reference leak in latency_switch_event", " - perf tools: Add bounds check to cpu__get_node()", " - perf sched: Cap max_cpu at MAX_CPUS in timehist sample processing", " - perf sched: Fix register_pid() overflow, strcpy, and BUG_ON", " - perf mmap: Guard cpu__get_node() return in aio_bind()", " - perf stat: Bounds-check CPU index in topology aggregation callbacks", " - perf c2c: Bounds-check CPU and node IDs before bitmap and array access", " - perf c2c: Bounds-check CPU IDs in setup_nodes() topology loop", " - perf sched: Clean up idle_threads entry on init failure", " - perf sched: Use thread__put() in free_idle_threads()", " - perf sched: Replace BUG_ON and add NULL checks in replay event helpers", " - perf mmap: Fix NULL deref in aio cleanup on alloc failure", " - perf stat: Introduce perf_env__get_cpu_topology() to guard NULL env->cpu", " - perf c2c: Fix use-after-free in he__get_c2c_hists() error path", " - perf timechart: Fix cpu2y() OOB read on untrusted CPU index", " - perf tools: Fix int16_t truncation of max_cpu_num in set_max_cpu_num()", " - dt-bindings: clock: qcom: Add X1P42100 camera clock controller", " - clk: qcom: camcc-x1e80100: Add support for camera QDSS debug clocks", " - mshv: add bounds check on vp_index in mshv_intercept_isr()", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - dmaengine: Fix possible use after free", " - dmaengine: dma-axi-dmac: Properly free struct axi_dmac_desc", " - dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - sunrpc: Fix error handling in rpc_sysfs_xprt_switch_add_xprt_store()", " - pNFS/filelayout: fix cheking if a layout is striped", " - NFSv4/pnfs: defer return_range callbacks until after inode unlock", " - nfs: keep PG_UPTODATE clear after read errors in page groups", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS on fatal DS connect", " errors", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - pwm: rzg2l-gpt: Add missing newlines to dev_err_probe() messages", " - PCI: meson: Propagate devm_add_action_or_reset() failure", " - PCI: meson: Add missing remove callback", " - fs/ntfs3: resize log->one_page_buf when adopting on-disk page size", " - platform/x86/intel/vsec: Decouple add/link helpers from PCI", " - platform/x86/intel/vsec: Switch exported helpers from pci_dev to device", " - platform/x86/intel/vsec: Return real error codes from registration path", " - platform/x86/intel/vsec: Restore BAR fallback for header walk", " - perf tools: Fix get_max_num() size_t underflow on empty sysfs file", " - perf tools: Use scnprintf() in cpu_map__snprint() to prevent overflow", " - perf tools: Use perf_env__get_cpu_topology() in machine__resolve()", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - perf sched: Bounds-check prio before test_bit() in timehist", " - perf sched: Fix idle-hist callchain display using wrong rb_first variant", " - perf bpf: Use scnprintf() in snprintf_hex() and", " synthesize_bpf_prog_name()", " - perf hists: Fix snprintf() in hists__scnprintf_title() UID filter path", " - xprtrdma: Fix ep kref imbalance on ADDR_CHANGE", " - xprtrdma: Initialize re_id before removal registration", " - xprtrdma: Check frwr_wp_create() during connect", " - xprtrdma: Document and assert reply-handler invariants", " - xprtrdma: Resize reply buffers before reposting receives", " - xprtrdma: Sanitize the reply credit grant after parsing", " - xprtrdma: Repost Receive buffers for malformed replies", " - xprtrdma: Return sendctx slot after Send preparation failure", " - perf s390: Fix TEXTREL in Python extension by compiling as PIC", " - perf cs-etm: Queue context packets for frontend", " - perf pmu: Fix pmu_id() heap underwrite on empty identifier file", " - perf pmu: Fix perf_pmu__parse_scale/unit() OOB access on empty sysfs", " file", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - perf symbols: Fix signed overflow in sysfs__read_build_id() size check", " - perf symbols: Bounds-check .gnu_debuglink section data", " - perf intel-pt: Fix snprintf size tracking bug in insn decoder", " - perf tools: Fix thread__set_comm_from_proc() on empty comm file", " - perf hwmon: Fix off-by-one null termination on sysfs reads", " - perf hwmon: Use scnprintf() in hwmon_pmu__for_each_event()", " - perf hwmon: Fix parse_hwmon_filename() strlcpy buffer overflow", " - perf symbols: Bounds-check descsz in sysfs__read_build_id() GNU fallback", " - perf hwmon: Guard label read against empty or failed reads", " - perf tools: Use snprintf() in dso__read_running_kernel_build_id()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - perf bpf: Add NULL check for btf__type_by_id() in", " synthesize_bpf_prog_name()", " - perf bpf: Fix map data leak in bpf_metadata_create() on alloc failure", " - perf bpf: Fix metadata leak in perf_env__add_bpf_info() on duplicate", " insert", " - perf symbols: Add bounds checks to elf_read_build_id() note iteration", " - perf symbols: Add bounds checks to read_build_id() note iteration in", " minimal build", " - dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on", " Purwa", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - phy: freescale: phy-fsl-imx8qm-lvds-phy: Fix missing", " pm_runtime_disable() on probe error path", " - PCI: dwc: Avoid dwc_pcie_rasdes_debugfs_deinit() NULL dereference when", " no RAS DES capability", " - Revert \"PCI/MSI: Unmap MSI-X region on error\"", " - apparmor: fix shadowing of plabel that prevents cache from being updated", " - apparmor: fix race in unix socket mediation when peer_path is used", " - apparmor: fix refcount leak when updating the sk_ctx", " - security/apparmor/apparmorfs.c: conditionally compile", " get_loaddata_common_ref()", " - apparmor: check label build before no_new_privs test", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [41/57]: apparmor-next 7.1:", " apparmor: fix rawdata_f_data implicit flex array\"", " - apparmor: fix rawdata_f_data implicit flex array", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [38/57]: apparmor-next 7.1:", " apparmor: grab ns lock and refresh when looking up changehat child", " profiles\"", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [44/57]: apparmor-next 7.1:", " apparmor: fix potential UAF in aa_replace_profiles\"", " - apparmor: fix potential UAF in aa_replace_profiles", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor: fix NULL pointer dereference in", " unpack_pdb\"", " - apparmor: fix NULL pointer dereference in unpack_pdb", " - apparmor: remove or add symlinks to rawdata according to export_binary", " - apparmor: Fix return in ns_mkdir_op", " - apparmor: fail policy unpack on accept2 allocation failure", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - apparmor: don't audit files pointing to aa_null.dentry", " - apparmor: fix uninitialised pointer passed to", " audit_log_untrustedstring()", " - i3c: mipi-i3c-hci: Preserve RUN bit when aborting DMA ring", " - i3c: master: Make hot-join workqueue freezable to block hot-join during", " suspend", " - i3c: master: Move rstdaa error suppression", " - i3c: master: Consolidate Hot-Join DAA work in the core", " - i3c: master: Ensure Hot-Join operations are stopped on shutdown", " - i3c: master: Defer new-device registration out of DAA caller context", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - accel/ivpu: fix HWS command queue leak on registration failure", " - sparc: led: avoid trimming a newline from empty writes", " - perf symbols: Fix bswap copy-paste error for 32-bit ELF p_filesz", " - perf symbols: Validate p_filesz before use in filename__read_build_id()", " - perf symbols: Break infinite loop on zero-filled notes in", " sysfs__read_build_id()", " - perf tools: Add O_CLOEXEC to open() calls in DSO and ELF code", " - perf tools: Fix uninitialized pathname on uncompressed fallback in", " filename__decompress()", " - perf dso: Fix heap overflow in dso__get_filename() on decompressed path", " - perf dso: Set error code when open() fails on uncompressed fallback path", " - perf tools: Use snprintf() for root_dir path construction", " - perf hwmon: Fix fd check to accept fd 0 in hwmon_pmu__describe_items()", " - perf sched: Replace (void*)1 sentinel with proper runtime allocation", " - perf bpf: Validate func_info_rec_size and sub_id in", " synthesize_bpf_prog_name()", " - perf bpf: Reject oversized BPF metadata events that truncate header.size", " - perf bpf: Bounds-check array offsets in bpil_offs_to_addr()", " - perf cs-etm: Reject CPU IDs that would overflow signed comparison", " - gpio: mlxbf3: fail probe if gpiochip registration fails", " - drm/i915: clear CRTC color blob pointers after dropping refs", " - drm/xe: Fix wa_oob codegen recipe for external module builds", " - spi: dw: fix wrong BAUDR setting after resume", " - i3c: master: Update dev_nack_retry_count under maintenance lock", " - i3c: master: Add missing runtime PM get in dev_nack_retry_count_store()", " - ALSA: usb-audio: qcom: Free sideband sg_table objects", " - xfrm: annotate data-races around xfrm_policy_count[] and", " xfrm_policy_default[]", " - xfrm: validate selector family and prefixlen during match", " - perf machine: Use snprintf() for guestmount path construction", " - perf cs-etm: Validate num_cpu before metadata allocation", " - perf cs-etm: Require full global header in auxtrace_info size check", " - perf cs-etm: Bounds-check CPU in cs_etm__get_queue()", " - perf bpf: Validate array presence before casting BPF prog info pointers", " - perf dso: Set standard errno on decompression failure", " - ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode", " - drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free", " - drm/amd/display: Fix mem_type change detection for async flips", " - drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm", " - drm/amdgpu: initialize irq.lock spinlock earlier", " - octeontx2-pf: Fix leak of SQ timestamp buffer on teardown", " - net: psample: fix info leak in PSAMPLE_ATTR_DATA", " - sctp: hold socket lock when dumping endpoints in sctp_diag", " - ALSA: usb-audio: qcom: reject stream disable with no active interface", " - ALSA: usb-audio: qcom: clear opened when stream enable fails", " - PCI: iproc: Restore .map_irq() for the platform bus driver", " - spi: rpc-if: Use correct device for hardware reinitialization on resume", " - virtio-net: fix len check in receive_big()", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - devlink: Fix parent ref leak in devl_rate_node_create()", " - devlink: Fix parent ref leak on tc-bw failure", " - net: airoha: fix foe_check_time allocation size", " - net: macb: add TX stall timeout callback to recover from lost TSTART", " write", " - flow_dissector: check device type before reading ETH_ADDRS", " - selftests: vlan_bridge_binding: Fix flaky operational state check", " - ALSA: usb-audio: Kill MIDI 2.0 URBs before freeing endpoints", " - arm64/hw_breakpoint: reject unaligned watchpoints that would truncate", " BAS", " - thermal: intel: Fix dangling resources on thermal_throttle_online()", " failure", " - ACPI: resource: Amend kernel-doc style", " - ACPI: IPMI: Fix inverted interface check in ipmi_bmc_gone()", " - ieee802154: Restore initial state on failed device_rename() in", " cfg802154_switch_netns()", " - ieee802154: Avoid calling WARN_ON() on -ENOMEM in", " cfg802154_switch_netns()", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " - mac802154: Prevent overwrite return code in", " mac802154_perform_association()", " - md/raid1: honor REQ_NOWAIT when waiting for behind writes", " - md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on", " retry", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " - netfilter: ipset: make sure gc is properly stopped", " - netfilter: nft_payload: reject offsets exceeding 65535 bytes", " - netfilter: nft_meta_bridge: add validate callback for get operations", " - netfilter: nft_flow_offload: zero device address for non-ether case", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " - mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()", " - irqchip/crossbar: Fix parent domain resource leak", " - alloc_tag: fix use-after-free in /proc/allocinfo after module unload", " - selftests/mm: restore default nr_hugepages value via exit trap in", " charge_reserved_hugetlb.sh", " - selftests/mm: restore default nr_hugepages value via exit trap in", " hugetlb_reparenting_test.sh", " - selftests/mm: fix hugetlb pathname construction in", " hugetlb_reparenting_test.sh", " - selftests/mm: fix cgroup task placement and drop memory.current checks", " in hugetlb_reparenting_test.sh", " - selftests/mm: size tmpfs according to PMD page size in", " split_huge_page_test", " - selftests/mm: free dynamically allocated PMD-sized buffers in", " split_huge_page_test", " - selftest/mm: register existing mapping with userfaultfd in hugetlb-", " mremap", " - selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap", " - selftests/mm: skip uffd-stress test when nr_pages_per_cpu is zero", " - selftests/mm: clarify alternate unmapping in compaction_test", " - selftests/mm: allow PUD-level entries in compound testcase of hmm tests", " - selftests/mm: fix exclusive_cow test fork() handling", " - net: marvell: prestera: initialize err in prestera_port_sfp_bind", " - tipc: fix use-after-free of the discoverer in tipc_disc_rcv()", " - net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths", " - octeontx2-af: mcs: Fix unsupported secy stats read", " - octeontx2-pf: Clear stats of all resources when freeing resources", " - octeontx2-pf: mcs: Fix mcs resources free on PF shutdown", " - net: emac: Fix NULL pointer dereference in emac_probe", " - net/sched: act_ct: fix nf_connlabels leak on two error paths", " - net: airoha: Fix skb->priority underflow in airoha_dev_select_queue()", " - ipv6: ndisc: fix NULL deref in accept_untracked_na()", " - dpaa2-switch: do not accept VLAN uppers while bridged", " - rtc: abx80x: fix the RTC_VL_CLR clearing all status flags", " - rtc: ds1307: handle oscillator stop flag for ds1337/ds1339/ds3231", " - bpf: Fix stack slot index in nospec checks", " - bpftool: Fix vmlinux BTF leak in cgroup commands", " - bpf: zero-initialize the fib lookup flow struct", " - bpf: Fix effective prog array index with BPF_F_PREORDER", " - power: sequencing: fix ABBA deadlock in pwrseq_device_unregister()", " - gpiolib: initialize return value in gpiochip_set_multiple()", " - drm/edid: fix OOB read in drm_parse_tiled_block()", " - PCI: endpoint: pci-epf-vntb: Add check to detect 'db_count' value of 0", " - PCI: endpoint: pci-epf-ntb: Add check to detect 'db_count' value of 0", " - ice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()", " - ice: fix AQ error code comparison in ice_set_pauseparam()", " - ice: call netif_keep_dst() once when entering switchdev mode", " - rtc: isl1208: Balance enable_irq_wake() with disable_irq_wake() on", " cleanup", " - ice: dpll: set pointers to NULL after kfree in ice_dpll_deinit_info", " - ice: dpll: fix memory leak in ice_dpll_init_info error paths", " - i40e: Fix i40e_debug() to use struct i40e_hw argument", " - rtc: msc313: fix NULL deref in shared IRQ handler at probe", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " - eth: bnxt: rename ring_err_stats -> ring_drv_stats", " - eth: bnxt: improve the timing of stats", " - ipv4: fib: Don't ignore error route in local/main tables.", " - md/raid5: use stripe state snapshot in break_stripe_batch_list()", " - md/raid5: avoid R5_Overlap races while breaking stripe batches", " - bpf: Disable xfrm_decode_session hook attachment", " - netfilter: nf_nat: avoid invalid nat_net pointer use on failed", " nf_nat_init()", " - netfilter: nf_conncount: prevent connlimit drops for early confirmed ct", " - netfilter: nft_synproxy: stop bypassing the priv->info snapshot", " - netfilter: nft_compat: ebtables emulation must reject non-bridge targets", " - gpio: davinci: fix IRQ domain leak on devm_kzalloc failure", " - NTB: epf: Make db_valid_mask cover only real doorbell bits", " - NTB: epf: Report 0-based doorbell vector via ntb_db_event()", " - NTB: epf: Fix doorbell bitmask and IRQ vector handling", " - alpha/PCI: Add security_locked_down() check to pci_mmap_resource()", " - alpha/PCI: Fix __pci_mmap_fits() overflow for zero-length BARs", " - net, bpf: check master for NULL in xdp_master_redirect()", " - net: do not acquire dev->tx_global_lock in netdev_watchdog_up()", " - net: dsa: sja1105: round up PTP perout pin duration", " - veth: fix NAPI leak in XDP enable error path", " - net: usb: lan78xx: restore VLAN and hash filters after link up", " - ipv6: fix error handling in disable_ipv6 sysctl", " - ipv6: fix error handling in ignore_routes_with_linkdown sysctl", " - ipv6: fix error handling in forwarding sysctl", " - ipv6: fix error handling in disable_policy sysctl", " - ipv6: fix state corruption during proxy_ndp sysctl restart", " - ipv6: fix missing notification for ignore_routes_with_linkdown", " - eth: fbnic: fix ordering of heartbeat vs ownership", " - thermal: testing: zone: Flush work items during cleanup", " - ACPI: processor_idle: Mark LPI enter functions as __cpuidle", " - smb/client: preserve errors from smb2_set_sparse()", " - rtc: ds1307: Fix off-by-one issue with wday for rx8130", " - rtc: cmos: unregister HPET IRQ handler on probe failure", " - net: dsa: realtek: fix memory leak in rtl8366rb_setup_led()", " - net: phy: realtek: Clear MDIO_AN_10GBT_CTRL_ADV10G bit", " - octeontx2-af: Validate NIX maximum LFs correctly", " - net: mvneta: re-enable percpu interrupt on resume", " - net: sungem: fix probe error cleanup", " - net: ethernet: sunplus: spl2sw: fix phy_node refcount leak in remove", " - LoongArch: Move struct kimage forward declaration before use", " - LoongArch: BPF: Fix outdated tail call comments", " - LoongArch: BPF: Fix off-by-one error in tail call", " - ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count", " - net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync", " - dt-bindings: net: renesas,ether: Drop example \"ethernet-phy-", " ieee802.3-c22\" fallback", " - selftests: tls: size splice_short pipe by page size", " - net: hns3: unify copper port ksettings configuration path", " - net: hns3: refactor MAC autoneg and speed configuration", " - net: hns3: fix permanent link down deadlock after reset", " - net: hns3: differentiate autoneg default values between copper and fiber", " - ALSA: FCP: Fix NULL pointer dereference in interface lookup", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - ACPI: RIMT: Only defer the IOMMU configuration in init stage", " - riscv: Fix 32-bit call_on_irq_stack() frame pointer ABI", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - net: pse-pd: scope pse_control regulator handle to kref lifetime", " - seg6: validate SRH length before reading fixed fields", " - qede: fix out-of-bounds check for cqe->len_list[]", " - sctp: fix SCTP_RESET_STREAMS stream list length limit", " - MIPS: DEC: Ensure RTC platform device deregistration upon failure", " - MIPS: mm: Add check for highmem before removing memory block", " - ASoC: codecs: lpass-va-macro: Fix LPASS Codec Version for SC7280", " - hwmon: adm1275: Prevent reading uninitialized stack", " - hwmon: (pmbus) Fix passing events to regulator core", " - hwmon: (aspeed-g6-pwm-tach) Guard fan RPM calculation against divide-by-", " zero", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " - net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy", " - net: libwx: fix VMDQ mask for 1-queue mode", " - net: gianfar: dispose irq mappings on probe failure and device removal", " - net/sched: sch_teql: Introduce slaves_lock to avoid race condition and", " UAF", " - bridge: stp: Fix a potential use-after-free when deleting a bridge", " - drm/panthor: Fix potential invalid pointer deref in", " group_process_tiler_oom()", " - drm/panthor: Don't overrule pending immediate ticks in", " sched_resume_tick()", " - drm/panthor: Fix a leak when a group is evicted before the tiler OOM is", " serviced", " - drm/panthor: Interrupt group start/resumption if group_bind_locked()", " fails", " - tracing/eprobes: Allow use of BTF names to dereference pointers", " - tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - tracing/fprobe: Fix NULL pointer dereference in fprobe_fgraph_entry()", " - tracing/probes: Make the $ prefix mandatory for comm access", " - irqchip/gic-v3-its: Fix OF node reference leak", " - irqchip/ts4800: Fix missing chained handler cleanup on remove", " - sctp: fix addr_wq_timer race in sctp_free_addr_wq()", " - virtio_net: disable cb when NAPI is busy-polled", " - cxgb4: Fix decode strings dump for T6 adapters", " - selftests: drv-net: tso: don't touch dangerous feature bits", " - net/sched: act_bpf: use rcu_dereference_bh() to read the filter", " - ksmbd: reject undersized DACLs before parsing ACEs", " - gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe", " - pinctrl: meson: restore non-sleeping GPIO access", " - net/sched: dualpi2: clear stale classification on filter miss", " - net/sched: hhf: clear heavy-hitter state on reset", " - fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid", " - afs: Fix error code in afs_extract_vl_addrs()", " - afs: Fix double netfs initialisation in afs_root_iget()", " - afs: use kvfree() to free memory allocated by kvcalloc()", " - afs: Remove erroneous seq |= 1 in volume lookup loop", " - afs: Fix bulk lookup malfunction due to change in dir_emit() API", " - afs: Fix misplaced inc of net->cells_outstanding", " - afs: Fix reinitialisation of the inode, in particular ->lock_work", " - afs: Fix callback service message parsers to pass through -EAGAIN", " - afs: Fix missing NULL pointer check in afs_break_some_callbacks()", " - afs: Fix vllist leak", " - afs: Fix lack of locking around modifications of net->cells_dyn_ino", " - afs: Fix premature cell exposure through /afs", " - afs: Fix the volume AFS_VOLUME_RM_TREE is set on", " - afs: Fix unchecked-length string display in debug statement", " - minix: avoid overflow in bitmap block count calculation", " - ovl: fix comment about locking order", " - iomap: guard io_size EOF trim against concurrent truncate underflow", " - netfs: Fix writethrough to use collection offload", " - netfs: Fix writeback error handling", " - netfs: Fix folio state after ENOMEM whilst under writeback iteration", " - drm/xe/pt: Fix NULL pointer dereference in xe_pt_zap_ptes_entry()", " - drm/xe/userptr: Hold notifier_lock for write on inject test path", " - drm/xe/hw_engine: Fix double-free of managed BO in error path", " - drm/xe/pf: Don't attempt to process FAST_REQ or EVENT relays", " - x86/uprobes: Keep shadow stack in sync for emulated CALLs", " - uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline", " - cifs: Fix missing credit release on failure in cifs_issue_read()", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - ata: libata-scsi: limit simulated SCSI command copy to response length", " - HID: picolcd: prevent NULL pointer dereference in", " picolcd_send_and_wait()", " - HID: core: Fix OOB read in hid_get_report for numbered reports", " - arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - HID: bpf: Fix hid_bpf_get_data() range check", " - selftests/hid: Load only requested struct_ops maps", " - selftests/hid: Cover hid_bpf_get_data() size overflow", " - arm64/sysreg: Fix BWE field encoding in ID_AA64DFR2_EL1", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " - netfilter: xt_u32: reject invalid shift counts", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " - netfilter: nft_set_rbtree: get command skips end element with open", " interval", " - netfilter: xt_connmark: reject invalid shift parameters", " - net/mlx5: LAG, MPESW, Fix missing complete() on devcom error", " - net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation", " - net/mlx5e: Fix HV VHCA stats agent registration race", " - net/mlx5e: Fix publication race for priv->channel_stats[]", " - net: microchip: vcap: fix races on the shared Super VCAP block", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " - net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload", " - amt: fix size calculation in amt_get_size()", " - Bluetooth: 6lowpan: hold L2CAP conn across debugfs control", " - Bluetooth: MGMT: Fix adv monitor add failure cleanup", " - Bluetooth: sco: Fix a race condition in sco_sock_timeout()", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " - Bluetooth: L2CAP: fix tx ident leak for commands without a response", " - ring-buffer: Fix event length with forced 8-byte alignment", " - accel/amdxdna: Use unsigned long for nr_pages in amdxdna_hmm_register()", " - net/tls: Consume empty data records in tls_sw_read_sock()", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - gpio: dwapb: reduce allocation to single kzalloc", " - gpio: dwapb: Defer clock gating until noirq", " - tracing: Make tracepoint_printk static as not exported", " - accel/amdxdna: Fix potential amdxdna_umap lifetime race", " - drm/v3d: Reject invalid indirect BO handle in indirect CSD setup", " - net: mdio: select REGMAP_MMIO instead of depending on it", " - net/sched: cake: reject overhead values that underflow length", " - octeontx2-pf: check DMAC extraction support before filtering", " - perf/x86/amd/core: Avoid enabling BRS from the SVM reload path", " - gpio: mvebu: free generic chips on unbind", " - ipv4: igmp: annotate data-races around im->users", " - ipv4: igmp: annotate data-races around timer-related fields", " - ipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and", " igmp_stop_timer()", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - s390/zcrypt: Remove the empty file", " - SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED", " - dm era: fix NULL pointer dereference in metadata_open()", " - regulator: core: regulator_lock_two() should test for EDEADLK not", " EDEADLOCK", " - selftests/net: fix EVP_MD_CTX leak in tcp_mmap", " - net/mlx5: Fix L3 tunnel entropy refcount leak", " - octeontx2-af: fix VF bringup affecting PF promiscuous state", " - drm/xe: remove duplicate include", " - smb: client: fix overflow in passthrough ioctl bounds check", " - idpf: add padding to PTP virtchnl structures", " - mlxsw: fix refcount leak in mlxsw_sp_port_lag_join()", " - mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()", " - vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter", " - ASoC: SOF: ipc4-control: Fix TOCTOU in sof_ipc4_bytes_put", " - ASoC: SOF: ipc3-control: Use overflow checks in control_update size calc", " - ASoC: SOF: ipc3-control: Fix TOCTOU in bytes_put and bytes_get", " - ASoC: SOF: topology: validate vendor array size before parsing", " - net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post()", " - net: atm: reject out-of-range traffic classes in QoS validation", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()", " - arm64: dts: s32g3: Fix SWT8 watchdog address", " - ARM: dts: imx6ul-var-som: fix warning for non-existent dc-supply", " property", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Ringneck", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix ADC sampling times", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move divergent mecio1 ADC", " channels to board files", " - arm64: dts: ti: k3-am62a7-sk: Add bootph-all tag to vqmmc", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Enable internal ADC reference", " - arm64: dts: imx8ulp-evk: Correct Type-C int GPIO flags", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix GPIO names typo", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move gpio-line-names to board", " files", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix expander gpio line typo", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move expander gpio-line-names to", " board files", " - LoongArch: KVM: Validate irqchip index in irqfd routing", " - LoongArch: KVM: Check irq validity in kvm_vcpu_ioctl_interrupt()", " - LoongArch: KVM: Check the return values for put_user()", " - LoongArch: KVM: Fix FPU register width with user access API", " - LoongArch: KVM: Return full old CSR value from kvm_emu_xchg_csr()", " - powerpc/pseries/Kconfig: Enable CONFIG_VPA_PMU to be used with KVM", " - KVM: s390: pci: Fix GISC refcount leak on AIF enable failure", " - KVM: s390: pci: Fix handling of AIF enable without AISB", " - KVM: SEV: Do not allow intra-host migration/mirroring of SNP VMs", " - KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs", " - KVM: x86: Nullify irqfd->producer if updating IRTE for bypass fails", " - KVM: nVMX: Put vmcs12 pages if nested VM-Enter fails due to invalid", " guest state", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " - KVM: arm64: nv: Drop bogus WARN for write to ZCR_EL2", " - KVM: arm64: nv: Write ESR_EL2 for injected nested SError exceptions", " - KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()", " - fbdev: metronomefb: fix potential memory leak in metronomefb_probe()", " - fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()", " - fbdev: hecubafb: fix potential memory leak in hecubafb_probe()", " - fbdev: sm712: Fix operator precedence in big_swap macro", " - fbdev: efifb: fix memory leak in efifb_probe()", " - fbdev: radeon: fix potential memory leak in radeonfb_pci_register()", " - fbdev: i740fb: fix potential memory leak in i740fb_probe()", " - fbdev: s3fb: fix potential memory leak in s3_pci_probe()", " - fbdev: uvesafb: fix potential memory leak in uvesafb_probe()", " - fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()", " - fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()", " - fbdev: vesafb: fix memory leak in vesafb_probe()", " - fbdev: nvidia: fix potential memory leak in nvidiafb_probe()", " - fbdev: tridentfb: fix potential memory leak in trident_pci_probe()", " - ASoC: SOF: ipc3-control: Fix heap overflow in bytes_ext put/get", " - ASoC: SOF: ipc3-control: Validate size in snd_sof_update_control", " - ASoC: mediatek: mt8192: Check runtime resume during probe", " - ASoC: mediatek: mt8192: Release reserved memory on cleanup", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - ASoC: mediatek: mt8183: Release reserved memory on cleanup", " - ASoC: qcom: q6apm: fix NULL pointer dereference in graph_callback", " - netfilter: nf_conntrack_irc: fix parse_dcc() off-by-one OOB read", " - netfilter: nfnl_cthelper: apply per-class values when updating policies", " - netfilter: xt_cluster: reject template conntracks in hash match", " - netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst", " - netfilter: nft_set_pipapo: don't leak bad clone into future transaction", " - netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6", " defrag", " - netfilter: nf_conncount: fix zone comparison in tuple dedup", " - netfilter: ecache: fix inverted time_after() check", " - netfilter: xt_nat: reject unsupported target families", " - netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()", " - gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error", " path", " - soc: ti: k3-ringacc: Fix access mode for", " k3_ringacc_ring_pop_tail_io/proxy", " - soc: fsl: qe: panic on ioremap() failure in qe_reset()", " - selinux: check connect-related permissions on TCP Fast Open", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - selinux: fix incorrect execmem checks on overlayfs", " - leds: uleds: Fix potential buffer overread", " - mfd: sm501: Fix reference leak on failed device registration", " - tools/power/x86/intel-speed-select: Harden daemon pidfile open", " - x86/boot: Validate console=uart8250 baud rate to fix early boot hang", " - x86/boot: Reject too long acpi_rsdp= values", " - perf/x86/amd/brs: Fix kernel address leakage", " - perf/x86/amd/lbr: Fix kernel address leakage", " - cpufreq: schedutil: Fix uncleared need_freq_update on the .adjust_perf()", " path", " - cpufreq: intel_pstate: Set non-turbo capacity to HWP_GUARANTEED_PERF()", " - s390/perf_cpum_cf: Add missing array_index_nospec() to", " __hw_perf_event_init()", " - batman-adv: gw: acquire ethernet header only after skb realloc", " - batman-adv: retrieve ethhdr after potential skb realloc on RX", " - batman-adv: dat: acquire ARP hw source only after skb realloc", " - batman-adv: bla: reacquire gw address after skb realloc", " - batman-adv: dat: ensure accessible eth_hdr proto field", " - batman-adv: ensure minimal ethernet header on TX", " - batman-adv: dat: fix tie-break for candidate selection", " - batman-adv: tt: avoid request storms during pending request", " - batman-adv: fix VLAN priority offset", " - batman-adv: frag: free unfragmentable packet", " - batman-adv: clean untagged VLAN on netdev registration failure", " - batman-adv: frag: fix primary_if leak on failed linearization", " - batman-adv: mcast: avoid OOB read of num_dests header", " - cifs: invalidate cfid on unlink/rename/rmdir", " - mfd: tps6586x: Fix OF node refcount", " - HID: playstation: validate num_touch_reports in DualShock 4 reports", " - Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready", " - Bluetooth: SCO: hold sk properly in sco_conn_ready", " - jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit()", " - nvdimm/btt: Free arenas on btt_init() error paths", " - nvdimm/btt: Free arena sub-allocations on discover_arenas() error path", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " - remoteproc: qcom: Fix leak when custom dump_segments addition fails", " - MIPS: ip22-gio: fix gio device memory leak", " - MIPS: ip22-gio: fix kfree() of static object", " - MIPS: ip22-gio: fix device reference leak in probe", " - MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf()", " - mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages", " - power: supply: cpcap-battery: Fix missing nvmem_device_put() causing", " reference leak", " - power: supply: max17042: fix OF node reference imbalance", " - mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch", " - mm/memory_hotplug: fix incorrect altmap passing in error path", " - mm/damon/core: make charge_addr_from aware of end-address exclusivity", " - fs/ntfs3: fix syncing wrong inode on DIRSYNC cross-directory rename", " - fs/ntfs3: bound DeleteIndexEntryAllocation memmove length", " - fs/ntfs3: bound copy_lcns dp->page_lcns[] index in analysis pass", " - fs/ntfs3: bound attr_off in UpdateResidentValue against data_off", " - fs/ntfs3: validate lcns_follow in log_replay conversion", " - fs/ntfs3: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - landlock: Fix LANDLOCK_SCOPE_SIGNAL bypass on the SIGIO path", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " - selftests/landlock: Test SCOPE_SIGNAL on the SIGIO/fowner pgid path", " - mips: sched: Fix CPUMASK_OFFSTACK memory corruption", " - riscv: cacheinfo: Fix node reference leak in populate_cache_leaves", " - mm/damon/sysfs-schemes: fix dir put orders in access_pattern_add_dirs()", " - mm/damon/sysfs-schemes: put stats for scheme_add_dirs() internal error", " - fs/proc/task_mmu: fix hugetlb self-deadlock in pagemap_scan_pte_hole()", " - fs/proc/task_mmu: use huge_page_size() in pagemap_scan_hugetlb_entry()", " - proc: only bump parent nlink when registering directories", " - fs/proc: fix KPF_KSM reported for all anonymous pages", " - powerpc/dt_cpu_ftrs: Set CPU_FTR_P11_PVR for Power11 and later", " processors", " - mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE", " - kcov: use WRITE_ONCE() for selftest mode stores", " - mtd: slram: remove failed entries from the device list", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - power: supply: bq257xx: Fix VSYSMIN clamping logic", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - scsi: sas: Skip opt_sectors when DMA reports no real optimization hint", " - openrisc: Add full instruction cache invalidate functions", " - ocfs2: use kzalloc for quota recovery bitmap allocation", " - mtd: rawnand: pl353: fix probe resource allocation", " - net/9p: fix infinite loop in p9_client_rpc on fatal signal", " - mtd: rawnand: fix condition in 'nand_select_target()'", " - ocfs2: avoid moving extents to occupied clusters", " - ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits", " - ocfs2: fix UBSAN array-index-out-of-bounds in ocfs2_sum_rightmost_rec", " - ocfs2: add journal NULL check in ocfs2_checkpoint_inode()", " - ocfs2: reject dinodes with non-canonical i_mode type", " - ocfs2: reject dinodes whose i_rdev disagrees with the file type", " - ocfs2: reject non-inline dinodes with i_size and zero i_clusters", " - fpga: dfl: add bounds check in dfh_get_param_size()", " - bus: mhi: host: pci_generic: Fix the physical function check", " - bus: mhi: ep: Protect mhi_ep_handle_syserr() in the error path", " - net: thunderbolt: Fix frags[] overflow by bounding frame_count", " - fpga: microchip-spi: fix zero header_size OOB read in", " mpf_ops_parse_header()", " - s390/pkey: Check length in PKEY_VERIFYPROTK ioctl", " - s390/pkey: Check length in pkey_pckmo handler implementation", " - mtd: spi-nor: swp: Improve locking user experience", " - mtd: spi-nor: spansion: use die erase for multi-die devices only", " - mtd: rawnand: Pause continuous reads at block boundaries", " - openrisc: Fix jump_label smp syncing", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - taskstats: retain dead thread stats in TGID queries", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - tpm: tpm2-sessions: wait for async KPP completion in tpm_buf_append_salt", " - sunrpc: fix uninitialized xprt_create_args structure", " - dmaengine: tegra: Fix burst size calculation", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - platform/x86: dell-laptop: fix missing cleanups in init error path", " - platform/x86: ISST: Restore SST-PP control to all domains", " - platform/x86/amd/pmc: Check for intermediate wakeup in function", " - platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops", " - platform/x86/amd/pmc: Add delay_suspend module parameter", " - platform/x86/amd/pmc: Don't log during intermediate wakeups", " - pkey: Move keytype check from pkey api to handler", " - smb: client: use kvzalloc() for megabyte buffer in simple fallocate", " - ksmbd: fix integer overflow in set_file_allocation_info()", " - hwmon: (ltc2992) add missing 'select REGMAP_I2C' to Kconfig", " - hwmon: (max6697) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", " - i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ)", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " - i2c: spacemit: fix spurious IRQ handling returning IRQ_HANDLED", " - ice: fix ice_init_link() error return preventing probe", " - tcp: Decrement tcp_md5_needed static branch", " - ufs: core: tracing: Do not dereference pointers in TP_printk()", " - xen/gntdev: fix error handling in ioctl", " - xfrm: use compat translator only for u64 alignment mismatch", " - xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for", " changelink", " - tpm: fix event_size output in tpm1_binary_bios_measurements_show", " - tpm: Make the TPM character devices non-seekable", " - time: Fix off-by-one in compat settimeofday() usec validation", " - spi: uniphier: Fix completion initialization order before", " devm_request_irq()", " - NFS: Charge unstable writes by request size, not folio size", " - nvme-apple: Prevent shared tags across queues on Apple A11", " - nvmet: fix refcount leak in nvmet_sq_create()", " - netdev-genl: report NAPI thread PID in the caller's pid namespace", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", " - can: isotp: serialize TX state transitions under so->rx_lock", " - can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF", " - can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure", " - can: bcm: add missing rcu list annotations and operations", " - bpf: Reset register bounds before narrowing retval range in", " check_mem_access()", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - bpf: Add missing access_ok call to copy_user_syms", " - block: remove redundant GD_NEED_PART_SCAN in add_disk_final()", " - block: fix race in blk_time_get_ns() returning 0", " - block: fix IORING_URING_CMD_REISSUE flags check in blkdev_uring_cmd", " - net: sparx5: unregister blocking notifier on init failure", " - dm thin metadata: fix superblock refcount leak on snapshot shadow", " failure", " - dm thin metadata: fix metadata snapshot consistency on commit failure", " - dm era: fix out-of-bounds memory access for non-zero start sector", " - dm-bufio: fix wrong count calculation in dm_bufio_issue_discard", " - dm-ioctl: fix a possible overflow in list_version_get_info", " - dm-log: fix a bitset_size overflow on 32bit machines", " - dm-pcache: reject option groups without values", " - dm-stats: fix dm_jiffies_to_msec64", " - dm-stats: fix merge accounting", " - dm_early_create: fix freeing used table on dm_resume failure", " - dm-integrity: fix leaking uninitialized kernel memory", " - dm-integrity: fix a bug if the bio is out of limits", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: avoid double increment of &use_bh_wq_enabled", " - dm-verity: fix a possible NULL pointer dereference", " - dm-verity: increase sprintf buffer size", " - dm-verity: make error counter atomic", " - dma-fence: Make dma_fence_dedup_array() robust against 0-count input", " - accel/amdxdna: Fix use-after-free in amdxdna_gem_dmabuf_mmap()", " - accel/ivpu: Reject firmware log with size smaller than header", " - scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path", " - scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()", " - scsi: sg: Report request-table problems when any status is set", " - scsi: xen: scsiback: Free the command tag on the TMR submit-failure path", " - scsi: elx: efct: Fix refcount leak in efct_hw_io_abort()", " - scsi: elx: efct: Fix I/O leak on unsupported additional CDB", " - Input: ims-pcu - fix use-after-free and double-free in disconnect", " - Input: ims-pcu - only expose sysfs attributes on control interface", " - Input: ims-pcu - release data interface on disconnect", " - Input: ims-pcu - validate control endpoint type", " - Input: ims-pcu - add response length checks", " - Input: ims-pcu - fix DMA mapping violation in line setup", " - Input: ims-pcu - fix firmware leak in async update", " - Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging", " - Input: ims-pcu - fix potential infinite loop in CDC union descriptor", " parsing", " - Input: ims-pcu - fix race condition in reset_device sysfs callback", " - Input: ims-pcu - fix type confusion in CDC union descriptor parsing", " - net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete", " - tracing/user_events: Fix use-after-free in user_event_mm_dup()", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " - selftests/ftrace: Drop invalid top-level local in test_ownership", " - cpu: hotplug: Preserve per instance callback errors", " - cpu: hotplug: Bound hotplug states sysfs output", " - gpio: mt7621: more robust management of IRQ domain teardown", " - gpio: tegra: do not call pinctrl for GPIO direction", " - gpio: mt7621: be sure IRQ domain is created before exposing GPIO chips", " - gpio-f7188x: Add support for NCT6126D version B", " - gpio: mt7621: avoid corruption of shared interrupt trigger state", " - gpios: palmas: add .get_direction() op", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " - net: ethernet: ti: icssg: guard PA stat lookups", " - net: wwan: t7xx: destroy DMA pool on CLDMA late init failure", " - net: ixp4xx_hss: fix duplicate HDLC netdev allocation", " - net/sched: act_ct: preserve tc_skb_cb across defragmentation", " - selftests: net: fix file owner for broadcast_ether_dst test", " - net: ena: clean up XDP TX queues when regular TX setup fails", " - net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ipip: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", " - octeontx2-af: Free BPID bitmap on setup failure", " - ieee802154: admin-gate legacy LLSEC dump operations", " - ieee802154: allow legacy LLSEC ADD/DEL ops to pass strict validation", " - ieee802154: ca8210: fix cas_ctl leak on spi_async failure", " - ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit", " - platform/x86/amd/pmc: Avoid logging \"(null)\" for DMI values", " - net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants", " - drm/xe/userptr: Stub notifier_lock helpers when DRM_GPUSVM=n", " - pwm: rzg2l-gpt: Fix period_ticks type from u32 to u64", " - LoongArch: Fix nr passing in set_direct_map_valid_noflush()", " - LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()", " - ipmi: Fix user refcount underflow in event delivery", " - ipmi: fix refcount leak in i_ipmi_request()", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " - rtc: renesas-rtca3: Fix PIE clear polling condition in alarm setup error", " path", " - rtc: mpfs: fix counter upload completion condition", " - hwmon: (w83627hf) remove VID sysfs files on error and remove", " - hwmon: (w83793) remove vrm sysfs file on probe failure", " - net: liquidio: fix BAR resource leak on PF number failure", " - hwmon: (occ) unregister sysfs devices outside occ lock", " - fsl/fman: Free init resources on KeyGen failure in fman_init()", " - net: lan743x: Initialize eth_syslock spinlock before use", " - net/sched: sch_multiq: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - net/sched: sch_taprio: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - fhandle: reject detached mounts in capable_wrt_mount()", " - hwmon: (max1619) add missing 'select REGMAP' to Kconfig", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - net/mlx5: HWS, fix matcher leak on resize target setup failure", " - ata: pata_pxa: Fix DMA channel leak on probe error", " - net: wwan: iosm: bound device offsets in the MUX downlink decoder", " - hwmon: (asus_atk0110) Check package count before accessing element", " - riscv: probes: save original sp in rethook trampoline", " - mm/compaction: handle free_pages_prepare() properly in compaction_free()", " - irqchip/irq-riscv-imsic-early: Fix fwnode leak on state setup failure", " - s390/monwriter: Reject buffer reuse with different data length", " - mac802154: remove interfaces with RCU list deletion", " - octeontx2-pf: fix SQB pointer leak on init failure", " - selftests: net: make busywait timeout clock portable", " - llc: fix SAP refcount leak in llc_ui_autobind()", " - ipvs: use parsed transport offset in SCTP state lookup", " - macsec: don't read an unset MAC header in macsec_encrypt()", " - dibs: loopback: validate offset and size in move_data()", " - net: macb: drop in-flight Tx SKBs on close", " - arm64: smp: Fix hot-unplug tearing by forcing unregistration", " - cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()", " - fs/resctrl: Free mon_data structures on rdt_get_tree() failure", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", " - ata: libata-core: Skip HPA resize for locked drives", " - ata: libata-core: Allow capacity transition to zero for locked drives", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " - tracing/osnoise: Call synchronize_rcu() when unregistering", " - s390/diag: Add missing array_index_nospec() call to", " memtop_get_page_count()", " - s390/mm: Fix type mismatch in get_align_mask().", " - selftests/rseq: Fix a building error for riscv arch", " - cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed", " - pmdomain: imx: Fix i.MX8MP power notifier", " - pmdomain: imx: Fix i.MX8MP VC8000E power up sequence", " - selftests/landlock: Skip scoped_signal subtest with MSG_OOB if not", " available", " - selftests/landlock: Fix screwed up pointers in the scoped_signal_test", " - mmc: sdhci-esdhc-imx: restore pinctrl before restoring ios timing on", " resume", " - powerpc/pseries: fix memory leak on krealloc failure in papr_init", " - net/mlx5: free mlx5_st_idx_data on final dealloc", " - wifi: rt2x00: avoid full teardown before work setup in probe", " - wifi: mwifiex: fix roaming to different channel in host_mlme mode", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " - wifi: brcmfmac: cyw: fix heap overflow on a short auth frame", " - riscv: vdso: Do not use LTO for the vDSO", " - regulator: ltc3676: Fix incorrect IRQSTAT bit offsets", " - Bluetooth: btrtl: validate firmware patch bounds", " - llc: fix SAP refcount leak when creating incoming sockets", " - macsec: fix promiscuity refcount leak in macsec_dev_open()", " - memstick: ms_block: reject a card that reports too many blocks", " - reset: sunxi: fix memory region leak on ioremap failure", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " - wifi: cfg80211: validate EHT MLE before MLD ID read", " - wifi: ieee80211: validate MLE common info length", " - wifi: mac80211: free ack status frame on TX header build failure", " - wifi: mwifiex: fix permanently busy scans after multiple roam iterations", " - mtd: onenand: samsung: report DMA completion timeouts", " - mtd: mchp23k256: use SPI match data for chip caps", " - mmc: vub300: defer reset until cmd_mutex is unlocked", " - mtd: rawnand: fsl_ifc: return errors for failed page reads", " - mtd: rawnand: lpc32xx_mlc: fail DMA transfers on timeout", " - mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout", " - mmc: block: fix RPMB device unregister ordering", " - mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe()", " method", " - mmc: sdhci-esdhc-imx: remove unnecessary mmc_card_wake_sdio_irq check", " for tuning save/restore", " - mmc: sdhci-esdhc-imx: restore DLL override for DDR modes on resume", " - mmc: sdhci-esdhc-imx: fix esdhc_change_pinstate() to allow default state", " restore", " - mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled", " interrupt", " - mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend", " - mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking in suspend", " - mmc: sdhci-esdhc-imx: fix resume error handling", " - crypto: xilinx-trng - Remove crypto_rng interface", " - ACPI: bus: Introduce devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Use devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Fix possible deadlock and missing notifications", " - iio: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - ALSA: scarlett2: Allow selecting config_set by firmware version", " - ALSA: scarlett2: Update offsets for 2i2 Gen 4 firmware 2417", " - firmware_loader: Add cancel helper for async requests", " - ALSA: hda/tas2781: Cancel async firmware request at unbind", " - binder: Use LIST_HEAD() to initialize on stack list head", " - binder: cache secctx size before release zeroes it", " - staging: rtl8723bs: fix spaces around binary operators", " - Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister", " - Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()", " - proc: rename proc_setattr to proc_nochmod_setattr", " - usb: dwc3: Support USB3340x ULPI PHY high-speed negotiation.", " - usb: dwc3: fix dwc3_readl() and dwc3_writel() calls in dwc3_ulpi_setup()", " - usb: atm: ueagle-atm: use dev_dbg() for 'device found' message", " - usb: atm: ueagle-atm: remove function entry/exit debug messages", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " - btrfs: remove folio parameter from ordered io related functions", " - KVM: arm64: Ensure level is always initialized when relaxing perms", " - KVM: arm64: Fix propagation of TLBI level in", " kvm_pgtable_stage2_relax_perms()", " - mm/damon/core: always put unsuccessfully committed target pids", " - mm/damon/core: trace esz at first setup", " - samples/damon/mtier: fail early if address range parameters are invalid", " - perf callchain: Handle multiple address spaces", " - soc: fsl: qe_ports_ic: Add missing cleanup on device removal", " - drm/rockchip: inno-hdmi: Switch to drmm_kzalloc()", " - accel/amdxdna: Create shared functions for AIE2 and AIE4", " - Revert \"UBUNTU: SAUCE: accel/amdxdna: Support sensors for column", " utilization\"", " - accel/amdxdna: Support sensors for column utilization", " - accel/amdxdna: Adjust size for copy_to_user()", " - accel/amdxdna: Handle DETACH_DEBUG_BO through config_debug_bo path", " - accel/amdxdna: Fix order of canceled mailbox messages", " - accel/amdxdna: Guard management mailbox channel cleanup against NULL", " pointer", " - drm/amdkfd: fix redundant MQD iterations in GFX v12.1", " - wifi: ath12k: Fix invalid IRQ requests during AHB probe", " - libbpf: Fix deduplication of typedef with base definitions", " - spi: atcspi200: Use helper function devm_clk_get_enabled()", " - spi: atcspi200: fix use-after-free when driver unbind", " - arm64: dts: rockchip: Fix vdec register blocks order on RK3576", " - arm64: dts: rockchip: Update vdec register blocks order on RK3588", " - dt-bindings: net: bluetooth: qualcomm: Fix WCN6855 regulator names", " - x86/bug: Add printf() validation to HAVE_ARCH_BUG_FORMAT_ARGS WARNs", " - arm64: dts: qcom: milos: Reduce rmtfs_mem size to 2.5MiB", " - arm64: dts: qcom: sdm845-oneplus: Drop address from framebuffer node", " - arm64: dts: qcom: sdm845-shift-axolotl: Correct touchscreen sleep state", " - soc: xilinx: Fix race condition in event registration", " - wifi: ath11k: cancel SSR work items during PCI shutdown", " - ixgbe: fix unaligned u32 access in ixgbe_update_flash_X550()", " - objtool/klp: Fix is_uncorrelated_static_local() for Clang", " - objtool/klp: Fix .data..once static local non-correlation", " - objtool/klp: Fix create_fake_symbols() skipping entsize-based sections", " - objtool/klp: Fix handling of zero-length .altinstr_replacement sections", " - objtool/klp: Fix cloning of zero-length section symbols", " - objtool/klp: Fix extraction of text annotations for alternatives", " - objtool/klp: Fix relocation conversion failures for R_X86_64_NONE", " - objtool/klp: Use sym->demangled_name for symbol_name hash", " - objtool/klp: Match symbols based on demangled_name for global variables", " - objtool: Replace iterator callback with for_each_sym_by_mangled_name()", " - objtool: Fix reloc hash collision in find_reloc_by_dest_range()", " - klp-build: Fix hang on out-of-date .config", " - klp-build: Fix checksum comparison for changed offsets", " - riscv: dts: microchip: gpio controllers on mpfs need 2 interrupt cells", " - riscv: dts: microchip: remove gpio hogs from beaglev-fire", " - wifi: cfg80211: restrict LMR feedback check to TB and non-TB ranging", " - drm/panel: Clean up SOFEF00 config dependencies", " - drm/panel: Clean up S6E3FC2X01 config dependencies", " - arm64: dts: marvell: samsung-coreprimevelte: Increase touchscreen", " voltage", " - arm64: dts: imx8mn-vhip4-evalboard-v1: Correct interrupt flags", " - arm64: dts: imx8mn-vhip4-evalboard-v2: Correct interrupt flags", " - crypto: ccp - Check for page allocation failure correctly in TIO", " - crypto: ccp - Initialize data during __sev_snp_init_locked()", " - accel/amdxdna: Fix clflush buffer size", " - ntb: Store original DMA address for future release", " - ntb: Use consistent DMA attributes when freeing DMA mappings", " - riscv: dts: spacemit: k3: add clock tree", " - dts: riscv: spacemit: correct 32k clock frequency", " - arm64: dts: qcom: sdm660: set cdsp compute-cbs' regs properly", " - arm64: dts: qcom: sdm630: set adsp compute-cbs' regs properly", " - arm64: dts: qcom: lemans: Move PCIe devices into soc node", " - sockptr: fix usize check in copy_struct_from_sockptr() for user pointers", " - arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling", " - rhashtable: give each instance its own lockdep class", " - thermal: hwmon: Register a hwmon device for each thermal zone", " - crypto: ccp/sev-dev-tsm - bail out early when pdev->bus is NULL", " - crypto: safexcel - Fix potential memory leak in safexcel_pci_probe()", " - net/sched: add qdisc_qlen_inc() and qdisc_qlen_dec()", " - net/sched: sch_dualpi2: annotate data-races in dualpi2_dump_stats()", " - tools/rtla: Fix --dump-tasks usage in timerlat", " - rtla: Stop the record trace on interrupt", " - dm: limit target bio polling to one shot", " - selftests/bpf: Override EXTRA_LDFLAGS for static builds", " - sched/fair: Update util_est after updating util_avg during dequeue", " - hfs: fix incorrect inode ID assignment in hfs_new_inode()", " - vfio: selftests: Fix out-of-tree build with make O=", " - vfio: selftests: Allow builds when ARCH=x86", " - vfio/xe: avoid duplicate reset in xe_vfio_pci_reset_done", " - arm64: dts: qcom: kaanapali: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sdm845-xiaomi-beryllium: Correct IPA FW path", " - ASoC: mediatek: mt8189: Fix probe resource cleanup", " - drm/msm/mdss: correct UBWC programming sequences", " - tools/nolibc: stackprotector: Avoid stalling program startup if crng is", " not init yet", " - ASoC: dapm: Fix widget lookup with prefixed names across DAPM contexts", " - ACPI: PAD: Fix teardown ordering in acpi_pad_remove()", " - wifi: ath12k: fix error unwind on arch_init() failure in PCI probe", " - cpufreq: governor: Fix data races on per-CPU idle/nice baselines", " - cpufreq: governor: Fix stale prev_cpu_nice spike when enabling", " ignore_nice_load", " - dt-bindings: vendor-prefixes: Add Verbatim Corporation", " - drm/tegra: fbdev: Do not assign to struct drm_fb_helper.info", " - rust: devres: add 'static bound to Devres", " - lib/base64: validate before writing in decode tail path", " - rust: uaccess: use INLINE_COPY_TO_USER to guard copy_to_user()", " - uaccess: unify inline vs outline copy_{from,to}_user() selection", " - uaccess: minimize INLINE_COPY_USER-related ifdefery", " - crypto: ccp/tsm - Enable the root port after the endpoint", " - firmware: samsung: acpm: Add devm_acpm_get_by_phandle helper", " - firmware: samsung: acpm: remove compile-testing stubs", " - drm/msm/a8xx: Make a8xx_recover IFPC safe", " - drm/msm/a8xx: Fix RSCC offset", " - EDAC/igen6: Fix memory topology parsing for Panther Lake-H SoCs", " - arm: dts: bcm2711: Fix typo in gpio-line-names", " - arm64: dts: renesas: r8a78000: Fix GIC-720AE View 1 Redistributor", " description", " - arm64: dts: renesas: ironhide: Describe all reserved memory", " - md: replace wait loop with wait_event() in md_handle_request()", " - md/raid1,raid10: fix deadlock in read error recovery path", " - md/raid1,raid10: fix error-path detection with md_cloned_bio()", " - md/raid1,raid10: fix bio accounting for split md cloned bios", " - liveupdate: Use refcount_t for FLB reference counts", " - liveupdate: Reference count incoming FLB data", " - liveupdate: skip serialization for context-preserving kexec", " - liveupdate: fix TOCTOU race in luo_session_retrieve()", " - liveupdate: block session mutations during reboot", " - spi: imx: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - wifi: ath12k: fix memory leak in ath12k_wifi7_dp_rx_h_verify_tkip_mic()", " - wifi: ath12k: fix inconsistent arvif state in vdev_create error paths", " - ACPI: button: Fix lid_device value leak past driver removal", " - drm/amd/pm: Add empty string validation to sysfs store functions", " - accel/amdxdna: Return errors for failed debug BO commands", " - mm: preserve PG_dropbehind flag during folio split", " - perf/x86/intel/uncore: Fix PCI device refcount leak in UPI discovery", " - wifi: wlcore: enable the right set of ciphers", " - cxl/test: Fix __fortify_panic", " - bpf: Take mmap_lock in zap_pages()", " - ocfs2: fix out-of-bounds write in ocfs2_remove_refcount_extent", " - cxl/pci: Fix the incorrect check of pci_read_config_word() return", " - cxl/pci: Convert PCIBIOS errors to errno on DVSEC config accesses", " - netfilter: cttimeout: detach dataplane timeout policy and repurpose", " refcount", " - arm64: dts: imx94: fix DDR PMU interrupt number", " - arm64: dts: freescale: fsl-ls1028a-tqmls1028a-mbls1028a: switch mmc", " aliases", " - selftests/bpf: Fix flaky file_reader test", " - riscv: alternative: Use IS_ENABLED() over ifdeffery for", " apply_vdso_alternatives()", " - riscv: alternative: Pass vDSO start as parameter to", " apply_vdso_alternatives()", " - riscv: alternative: Also patch the CFI vDSO", " - bpf: Verifier support for sleepable tracepoint programs", " - bpf: Reject sleepable BPF_LSM_CGROUP programs at load time", " - netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag", " - filelock: fix break_lease() stub signature for CONFIG_FILE_LOCKING=n", " - wifi: mac80211: bound S1G TIM PVB walk to the TIM element", " - ACPI: processor: Add cpuidle driver check in", " acpi_processor_register_idle_driver()", " - RDMA/nldev: Fix locking when accessing mr->pd", " - scsi: ufs: core: Handle PM commands timeout before SCSI EH", " - iommufd: Destroy the pages content after detaching from dmabuf", " - lib/test_hmm: fix memory leak in dmirror_migrate_to_system()", " - rust: kbuild: show the right `quiet_cmd_rustc_procmacrolibrary`", " - remoteproc: qcom_q6v5_wcss: drop redundant wcss_q6_bcr_reset", " - wifi: mt76: mt7996: remove redundant pdev->bus check in probe", " - wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits", " - memory: tegra186-emc: stop borrowing MC aggregate hook for EMC", " - PM: QoS: Fix misc device registration unwind", " - btrfs: lzo: reject compressed segment that overflows the compressed", " input", " - ixgbe: do not configure xps for XDP queues", " - bpf: Cancel special fields on map value recycle", " - clocksource: move NXP timer selection to drivers/clocksource", " - [Config] Allow certain NXP timer selections for arm64", " - vduse: fix compat handling for VDUSE_IOTLB_GET_FD/VDUSE_VQ_GET_INFO", " - iomap: pass the correct len to fserror_report_io in __iomap_write_begin", " - ASoC: cs35l56: Prevent double-free of debugfs", " - ASoC: cs35l56: Cleanup if component_probe fails", " - hwmon: (gpd-fan): drop global driver data and use per-device allocation", " - hwmon: (gpd-fan): Initialize EC before registering hwmon device", " - hwmon: (gpd-fan): fix race condition between device removal and sysfs", " access", " - ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT", " - cxl/test: Verify cmd->size_in before accessing payload", " - m68k: mcf5441x: fix clocks numbering", " - pinctrl: airoha: an7583: add missed gpio32 pin group", " - pinctrl: airoha: an7583: fix misprint in gpio19 pinconf", " - pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin", " function", " - pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin", " function", " - pinctrl: airoha: fix pwm pin function for an7581 and an7583", " - pinctrl: airoha: an7583: fix gpio21 pin group", " - pinctrl: airoha: an7583: add missed gpio22 pin group", " - pinctrl: airoha: an7583: fix phy1_led1 pin function", " - pinctrl: airoha: an7583: remove undefined groups from pcm_spi pin", " function", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_setup() for non-", " serdev device", " - Bluetooth: btintel: Replace CNVi id with hardware variant", " - Bluetooth: btintel: Add DSBR support for ScP2 onwards", " - Bluetooth: btintel_pcie: Load IOSF debug regs by controller variant", " - ASoC: cs35l56: Fix wrong error test on simple_write_to_buffer()", " - ASoC: SOF: Intel: select SND_SOC_SDW_UTILS=y from", " SND_SOC_SOF_HDA_GENERIC=y", " - ASoC: meson: aiu: Validate written enum values", " - ASoC: topology: Check PCM and DAI name strings before use", " - ipv4: fib: Don't dump dying fib_info in fib_leaf_notify().", " - iommu/dma-iommu: Fix wrong scatterlist length assignment in P2PDMA path", " - iommufd: Clarify IOAS_MAP_FILE dma-buf support", " - cxl/region: Fill first free targets[] slot during auto-discovery", " - vfio: selftests: Ensure libvfio output dirs are always created", " - cxl/region: Block region delete during region creation", " - cxl/region: Resolve region deletion races", " - cxl/memdev: Pin parents for entire memdev lifetime", " - net: airoha: Fix error handling in airoha_ppe_flush_sram_entries()", " - netfilter: nft_fwd_netdev: use recursion counter in neigh egress path", " - netfilter: nf_dup_netdev: add nf_dev_xmit_recursion*() helpers and use", " them", " - geneve: Fix off-by-one comparing with GRO_LEGACY_MAX_SIZE", " - smb: client: fix conflicting option validation for new mount API", " - btrfs: Drop WQ_PERCPU from ordered_flags in btrfs_init_workqueues()", " - bpf: Guard __get_user acesss with access_ok for uprobe_multi data", " - net: ti: icssg-prueth: Fix AF_XDP fill ring alloc and wakeup condition", " - net: ti: icssg: Use undirected TX tag for native XDP in HSR offload mode", " - net: ti: icssg: Use undirected TX tag for XDP zero copy in HSR offload", " mode", " - RDMA/bnxt_re: Free CQ toggle page after firmware teardown", " - RDMA/bnxt_re: Reject GET_TOGGLE_MEM when toggle page was not allocated", " - RDMA/hns: Fix memory leak of bonding resources", " - mfd: bd72720: Drop BUCK11 ID", " - 9p: Add missing read barrier in virtio zero-copy path", " - perf dwarf-aux: Fix libdw segmentation fault in cu_walk_functions_at", " - perf dwarf-aux: Fix libdw API contract violations", " - perf srcline: Introduce inline_node__clear_frames()", " - perf libdw: Fix libdw API contract violations and memory leaks", " - perf probe-finder: Fix libdw API contract violations", " - perf annotate-data: Fix libdw API contract violations", " - coresight: tmc: Fix overflow when calculating is bigger than 2GiB", " - perf tool: Fix missing schedstat delegates and dont_split_sample_group", " in delegate_tool", " - PCI: intel-gw: Move interrupt enable to own function", " - PCI: intel-gw: Enable clock before PHY init", " - PCI: intel-gw: Add .start_link() callback", " - bus: mhi: ep: Add missing state_lock protection for mhi_state access", " - PCI: dwc: Apply ECRC workaround for DesignWare cores prior to 5.10a", " - PCI: qcom: Set max OPP before DBI access during resume", " - perf pmu-events AMD: Switch l2_itlb_misses to", " bp_l1_tlb_miss_l2_tlb_miss.all", " - perf unwind: Refactor get_entries to allow dynamic libdw/libunwind", " selection", " - coresight: Handle helper enable failure properly", " - mailbox: don't free the channel if the startup callback failed", " - PCI/pwrctrl: Lock device when calling device_is_bound()", " - coresight: platform: defer connection counter increment until alloc", " succeeds", " - platform/x86: classmate-laptop: Address memory leaks on driver removal", " - clk: microchip: mpfs-ccc: fix peripheral driver registration failures", " after oob fix", " - perf sample: Add evsel to struct perf_sample", " - perf event: Fix size of synthesized sample with branch stacks", " - perf inject: Fix itrace branch stack synthesis", " - gpib: cb7210: Fix region leak when request_irq fails", " - timers/migration: Update stale @online doc to @available", " - clk: spacemit: k3: Switch to pll2_d6 as parent for PCIe clock", " - clk: spacemit: k3: Fix PCIe clock register offset", " - fs/ntfs3: fix wrong LCN in run_remove_range() when splitting a run", " - ntfs3: Allocate iomap inline_data using alloc_page", " - perf sample: Add file_offset field to struct perf_sample", " - perf sched: Replace BUG_ON on invalid CPU with graceful skip", " - perf sched: Fix NULL dereference in latency_runtime_event", " - perf sched: Fix comp_cpus heap overflow with cross-machine recordings", " - perf tools: Guard remaining test_bit calls from OOB sample CPU", " - perf sched: Fix thread reference leaks in timehist_get_thread()", " - perf sched: Use is_idle_sample() for idle thread runtime cast guard", " - perf sched: Fix thread reference leak in idle hist processing", " - perf sched: Free callchain nodes in idle thread cleanup", " - docs: memfd_preservation: fix rendering of ABI documentation", " - virtio: add missing kernel-doc for map and vmap members", " - fs/ntfs3: prevent potential lcn remains uninitialized", " - perf tools: NULL bitmap pointers after bitmap_free()", " - perf tools: Use scnprintf() in build_id__snprintf() and hwmon", " read_events()", " - perf data convert json: Fix addr_location leak on time-filtered samples", " - perf tools: Use mkostemp() for O_CLOEXEC on temporary files", " - phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put", " in reset", " - sparc: Avoid -Wunused-but-set-parameter in clear_user_page()", " - apparmor: release exe file resources on path failure", " - apparmor: remove unnecessary goto and associated label", " - apparmor: Fix inverted comparison in cache_hold_inc()", " - i3c: mipi-i3c-hci: Fix suspend behavior when bus disable falls back to", " software reset", " - i3c: master: Serialize i3c_set_hotjoin() with the maintenance lock", " - i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev()", " - perf maps: Add maps__mutate_mapping", " - perf c2c: Free format list entries when releasing c2c hist entries", " - regcache: Do not overwrite error code when finalizing cache after error", " - erofs: call erofs_exit_ishare() before rcu_barrier()", " - perf c2c: Free format list entries when c2c_hists__init() fails", " - perf c2c: Fix hist entry and format list leaks in c2c_he_free()", " - drm/amd/display: Skip PHY SSC reduction on some 8K panels", " - net: ethernet: mtk_eth_soc: fix supported_interface set after", " phylink_create", " - selftests/ftrace: Fix trace_marker_raw test on 64K page kernels", " - octeontx2-af: npc: Log successful MCAM drop-on-non-hit install at debug", " level", " - netconsole: don't drop the last byte of a full-sized message", " - eth: fbnic: take netif_addr_lock_bh() around rx mode address programming", " - arm64: static_call: include asm/insns.h", " - md/raid1: fix writes_pending and barrier reference leaks on write", " failures", " - md/raid10: fix writes_pending leak on write request failures", " - md/raid10: fix writes_pending and barrier reference leaks on discard", " failures", " - netfilter: ipset: Don't use test_bit() in lockless RCU readers in bitmap", " types", " - selftests/mm: fix hugetlb pathname construction in", " charge_reserved_hugetlb.sh", " - selftests/mm: run_vmtests.sh: free memory if available memory is low", " - selftests/mm: move hwpoison setup into run_test() and silence modprobe", " output for memory-failure category", " - selftests/mm: remove hardcoded THP sizing assumptions in hmm tests", " - net: dst_metadata: fix false-positive memcpy overflow in tun_dst_unclone", " - bpf: Fix partial copy of non-linear test_run output", " - bpf: Fix BPF_PROG_ASSOC_STRUCT_OPS last field check", " - erofs: handle 48-bit blocks_hi for compressed inodes", " - ASoC: cs530x: Fix expected MCLK rates for CS5302/4/8", " - PCI: endpoint: pci-epf-vntb: Document legacy MSI doorbell offset", " - PCI: endpoint: pci-epf-vntb: Defer pci_epc_raise_irq() out of atomic", " context", " - PCI: endpoint: pci-epf-vntb: Report 0-based doorbell vector via", " ntb_db_event()", " - e1000e: Reconfigure PLL clock gate timeout and re-enable K1 on Meteor", " Lake", " - bpf: Guard conntrack opts error writes", " - selftests/bpf: Cover small conntrack opts error writes", " - netfilter: nf_conntrack_helper: dynamically allocate struct", " nf_conntrack_helper", " - netfilter: nf_conntrack_pptp: move GRE specific cleanup to GRE tracker", " - netfilter: nf_conntrack_gre: fix gre keymap list corruption", " - netfilter: conntrack: check NULL when retrieving ct extension", " - netfilter: nf_conntrack_expect: use conntrack GC to reap expectations", " - netfilter: nf_conntrack_expect: store master_tuple in expectation", " - netfilter: nf_conntrack_expect: run expectation eviction with no helper", " - netfilter: nft_ct: expectation timeouts are passed in milliseconds", " - netfilter: nf_conntrack_helper: cap maximum number of expectation at", " helper registration", " - cpuidle: Allow exit latency to exceed target residency", " - ASoC: SDCA: Validate written enum value in ge_put_enum_double()", " - ASoC: rt5575: Use __le32 for SPI burst write address", " - PCI: endpoint: pci-epf-vntb: Exclude reserved slots from db_valid_mask", " - net: ti: icssg: Fix XSK zero copy TX during application wakeup", " - net: lwtunnel: Drop skb metadata before LWT encapsulation", " - sctp: fix err_chunk memory leaks in INIT handling", " - net: dsa: mxl862xx: avoid unaligned 16-bit access in api_wrap", " - octeontx2-af: fix CGX debugfs RVU AF PCI reference leaks", " - geneve: gate GRO hint in geneve_gro_complete() on gs->gro_hint", " - geneve: validate inner network offset in geneve_gro_complete()", " - tools: ynl: build archives with $(AR)", " - net: enetc: fix potential divide-by-zero when num_vsi is zero", " - udp_tunnel: Pass struct sock to setup_udp_tunnel_sock().", " - tipc: avoid busy looping in tipc_exit_net()", " - bpf: Mask pseudo pointer values in verifier logs", " - bpf: Fix insn_aux_data leak on verifier err_free_env path", " - hwmon: (pmbus/core) Add support for NVIDIA nvidia195mv mode", " - hwmon: (pmbus/core) honor vrm_version in pmbus_data2reg_vid()", " - gpio: shared-proxy: always serialize with a sleeping mutex", " - drm/panthor: Always use the IRQ-safe variant when acquiring the fence", " lock", " - drm/panthor: Keep the reset work disabled until everything is", " initialized", " - drm/panthor: Fix panthor_pwr_unplug()", " - spi: rzv2h-rspi: Fix DMA transfer error handling for signal interruption", " - xen/pvcalls: bound backend response req_id before indexing rsp[]", " - afs: Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints", " - afs: Fix directory inode initialisation order", " - afs: Use scoped_seqlock_read() rather than manually doing seqlock stuff", " - afs: Fix leak of ungot volume", " - iomap: release pages on atomic dio size mismatch", " - cachefiles: Fix double unlock in nomem_d_alloc error path", " - cachefiles: Fix file burial to take lock when unsetting S_KERNEL_FILE", " - drm/imagination: Fix returned size for DRM_IOCTL_PVR_DEV_QUERY", " - iio: dac: mcp47feb02: Fix passing uninitialized vref1_uV for no Vref1", " case", " - net/mlx5: LAG, replace pf array with xarray", " - net/mlx5: LAG, use xa_alloc to manage LAG device indices", " - net/mlx5: Lag: refactor representor reload handling", " - net/mlx5: E-Switch, add representor lifecycle lock", " - net/mlx5: Lag, avoid LAG and representor lock cycles", " - net/mlx5: LAG, factor out shared FDB code into dedicated file", " - net/mlx5: LAG, replace peer count check with direct peer lookup", " - net/mlx5: LAG, prepare for SD device integration", " - net/mlx5: LAG, replace mlx5_get_dev_index with LAG sequence number", " - net/mlx5: LAG, extend shared FDB API with group_id filter", " - net/mlx5: LAG, Fix off-by-one in single-FDB error rollback", " - ksmbd: fix multichannel binding and enforce channel limit", " - smb: client: preserve leading slash for POSIX absolute symlink targets", " - gpio: shared: make the voting mechanism adaptable", " - drm/i915/ltphy: Fix SSC Enablement bit in PORT_CLOCK_CTL", " - Bluetooth: 6lowpan: avoid untracked enable work", " - Bluetooth: btintel_pcie: Support Product level reset", " - [Config] Make BT_INTEL_PCIE depend on ACPI", " - Bluetooth: btintel_pcie: Add support for smart trigger dump", " - Bluetooth: btintel_pcie: Separate coredump work from RX work", " - Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe()", " - Bluetooth: ISO: fix malformed ISO_END/CONT handling", " - accel/amdxdna: Prevent PM resume deadlock in hwctx_sync_debug_bo()", " - accel/amdxdna: Fix VMA access race", " - net: rnpgbe: fix mailbox endianness and remove pointer casts", " - drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE", " - smb: client: fix busy dentry warning on unmount after DIO", " - drm/fb-helper: Only consider active CRTCs for vblank sync", " - ethtool: rss: Fix hfunc and input_xfrm parsing on big endian", " - drm/imagination: make pvr_fw_trace_init_mask_ops static", " - VDUSE: avoid leaking information to userspace", " - ASoC: SOF: ipc4-control: Validate notification payload size", " - arm64: dts: renesas: ironhide: Describe inline ECC carveouts", " - arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers", " - KVM: s390: vsie: Fix allocation of struct vsie_rmap", " - KVM: s390: vsie: Add missing radix_tree_preload() in", " _gaccess_shadow_fault()", " - KVM: s390: Add some useful mask macros", " - KVM: s390: vsie: Fix rmap handling in _do_shadow_crste()", " - KVM: s390: vsie: Fix redundant rmap entries", " - KVM: s390: vsie: Use mmu cache to allocate rmap", " - KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory", " - KVM: TDX: Reject concurrent change to CPUID entry count", " - ASoC: SOF: topology: fix memory leak in snd_sof_load_topology", " - netfilter: nft_fib: reject fib expression on the netdev egress hook", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", " - gpu/buddy: bail out of try_harder when alignment cannot be honoured", " - backlight: ktd2801: Enable BL_CORE_SUSPENDRESUME", " - cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size", " - pinctrl: renesas: rzg2l: Use -ENOTSUPP instead of -EOPNOTSUPP", " - remoteproc: xlnx: Check remote core state", " - mm/sparse-vmemmap: fix vmemmap accounting underflow", " - mm/huge_memory: preserve pmd_swp_uffd_wp on device-private PMD downgrade", " - fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race", " - fs/proc/task_mmu: do not warn on seeing non-migration pmd entry", " - kho: make sure scratch size is always aligned by CMA_MIN_ALIGNMENT_BYTES", " - mtd: maps: vmu-flash: fix fault in unaligned fixup", " - dmaengine: dw-edma-pcie: Reject devices without driver data", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", " - platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8D26)", " - platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8E35)", " - spi: imx: reconfigure for PIO when DMA cannot be started", " - ovl: use linked upper dentry in copy-up tmpfile", " - can: bcm: add locking when updating filter and timer values", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", " - can: bcm: fix CAN frame rx/tx statistics", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", " - can: bcm: fix stale rx/tx ops after device removal", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", " - can: bcm: add missing device refcount for CAN filter removal", " - selftests/bpf: Cover negative buffer pointer offsets", " - dm: avoid leaking the caller's thread keyring via the table device file", " - dma-buf: protected fence ops by RCU v8", " - dma-fence: use correct callback in dma_fence_timeline_name()", " - accel/amdxdna: reject command submission on devices without a submit op", " - accel/amdxdna: reject user command submission without a command BO", " - accel/amdxdna: Use caller client for debug BO sync", " - fs/resctrl: Fix use-after-free during unmount", " - mmc: vub300: fix use-after-free on probe failure", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", " - ksmbd: fix stack buffer overflow in multichannel session-key copy", " - netfilter: nfnetlink_cthelper: cap to maximum number of expectation per", " master", " - netfilter: nfnetlink_cthelper: cap to maximum number of expectation per", " master on updates", " - riscv: vdso: Always declare vdso_start symbols", " - ata: libata-core: Add NOLPM quirk for PNY CS900 1TB SSD", " - ata: libata-core: Reject an invalid concurrent positioning ranges count", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - amdkfd: properly free secondary context id", " - pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI", " - pmdomain: mediatek: Fix possible nullptr KP in HWV cleanup/on-check", " - arch/riscv: vdso: remove CFI landing pad from rt_sigreturn", " - reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ", " - powerpc/uaccess: correct check for CONFIG_PPC_E500 in", " mask_user_address()", " - wifi: mac80211: validate extension-frame layout before RX", " - xfs: factor out a xfs_zone_mark_free helper", " - xfs: add newly added RTGs to the free pool in growfs", " - liveupdate: validate session type before performing operation", " - posix-timers: Expand timer_[re]arm() callbacks with a boolean return", " value", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", " - Revert \"gpib: cb7210: Fix region leak when request_irq fails\"", " - Upstream stable to v6.18.40, v7.1.5", "", " * Resolute update: upstream stable patchset 2026-08-20 (LP: #2164666) //", " CVE-2023-20585", " - iommu/amd: Use maximum Event log buffer size when SNP is enabled on", " Family 0x19", " - iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family", " 0x19", "", " * [Regression] Laptop fails to power off completely when HDMI is connected", " in kernel 7.0.0-28 (LP: #2163121) // CVE-2026-68364", " - drm/amd/display: fix NULL ptr deref in ISM delayed work", " - drm/amd/display: Fix ISM teardown crash from NULL dc dereference", " - drm/amd/display: Fix ISM dc_lock deadlock during suspend", "", " * CVE-2026-72064", " - net: mana: Sync page pool RX frags for CPU", "", " * CVE-2026-72065", " - net: mana: Validate the packet length reported by the NIC", "", " * CVE-2026-72098", " - dm-verity-fec: replace {MAX,MIN}_RSN with {MIN,MAX}_ROOTS", " - dm-verity: fix buffer overflow in FEC calculation", "", " * CVE-2026-72248", " - netfilter: flowtable: support IPIP tunnel with direct xmit", " - netfilter: flowtable: use correct direction to set up tunnel route", "", " * CVE-2026-72249", " - netfilter: flowtable: use dst in this direction when pushing IPIP header", "", " * CVE-2026-72287", " - KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\"", " checks", "", " * CVE-2026-72329", " - net/liquidio: drop cached VF pci_dev LUT", "", " * CVE-2026-72355", " - netfs: Fix barriering when walking subrequest list", "", " * CVE-2026-72412", " - s390/mm: Fix handling of _PAGE_UNUSED pte bit", "", " * CVE-2026-72417", " - netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto()", "", " * CVE-2026-72442", " - netfilter: flowtable: fix and simplify IP6IP6 tunnel handling", "", " * CVE-2026-72463", " - xfrm: Fix dev use-after-free in xfrm async resumption", "", " * CVE-2026-72477", " - fs/ntfs3: call _ntfs_bad_inode() when failing to rename", "", " * CVE-2026-72493", " - net: serialize netif_running() check in enqueue_to_backlog()", "", " * CVE-2026-72494", " - RDMA/irdma: Replace waitqueue and flag with completion", "", " * CVE-2026-72496", " - RDMA/bnxt_re: Proper rollback if the ioremap fails", "", " * CVE-2026-74269", " - bnxt: fix head underflow on XDP head-grow", "", " * CVE-2026-74350", " - ocfs2: validate fast symlink target during inode read", "", " * CVE-2026-72495", " - RDMA/bnxt_re: Avoid repeated requests to allocate WC pages", "", " * CVE-2026-72501", " - RDMA/bnxt_re: Initialize dpi variable to zero", "", " * CVE-2026-72278", " - KVM: arm64: nv: Re-translate VNCR before injecting abort", "", " * CVE-2026-68083", " - ksmbd: fix path resolution in ksmbd_vfs_kern_path_create", "", " * CVE-2026-68457", " - ksmbd: use opener credentials for FSCTL mutations", "", " * CVE-2026-68476", " - ipvs: reload ip header after head reallocation", "", " * CVE-2026-68477", " - ipvs: fix more places with wrong ipv6 transport offsets", "", " * CVE-2026-72014", " - drbd: reject data replies with an out-of-range payload size", "", " * CVE-2026-72020", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", "", " * CVE-2026-72033", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", "", " * CVE-2026-72041", " - espintcp: use sk_msg_free_partial to fix partial send", "", " * CVE-2026-72046", " - gve: fix header buffer corruption with header-split and HW-GRO", "", " * CVE-2026-72069", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", "", " * CVE-2026-72083", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", "", " * CVE-2026-72084", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", "", " * CVE-2026-72085", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", "", " * CVE-2026-72129", " - nvmet-rdma: handle inline data with a nonzero offset", "", " * CVE-2026-72130", " - nvmet-auth: reject short AUTH_RECEIVE buffers", "", " * CVE-2026-64551", " - sctp: validate STALE_COOKIE cause length before reading staleness", "", " * CVE-2026-72137", " - xfrm: nat_keepalive: avoid double free on send error", "", " * CVE-2026-72139", " - tcp: defer md5sig_info kfree past RCU grace period in tcp_connect", "", " * CVE-2026-72191", " - ntfs3: validate split-point offset in indx_insert_into_buffer", "", " * CVE-2026-72192", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", "", " * CVE-2026-72194", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", "", " * CVE-2026-72217", " - SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing", "", " * CVE-2026-72220", " - sunrpc: harden rq_procinfo lifecycle to prevent double-free", "", " * CVE-2026-72221", " - sunrpc: wait for in-flight TLS handshake callback when cancel loses race", "", " * CVE-2026-72222", " - sunrpc: pin svc_xprt across the asynchronous TLS handshake callback", "", " * CVE-2026-72226", " - batman-adv: tt: prevent TVLV OOB check overflow", "", " * CVE-2026-72234", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", "", " * CVE-2026-72251", " - netfilter: nf_nat_sip: reload possible stale data pointer", "", " * CVE-2026-72277", " - KVM: arm64: nv: Inject SEA if kvm_translate_vncr() can't resolve PFN", " - KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory", "", " * CVE-2026-72279", " - KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR", "", " * CVE-2026-72288", " - KVM: arm64: vgic: Handle race between interrupt affinity change and LPI", " disabling", "", " * CVE-2026-72289", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", "", " * CVE-2026-72296", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", "", " * CVE-2026-72299", " - tipc: restrict socket queue dumps in enqueue tracepoints", "", " * CVE-2026-72317", " - SUNRPC: pin upper rpc_clnt across the TLS connect_worker", "", " * CVE-2026-72318", " - cifs: validate DFS referral string offsets", "", " * CVE-2026-72319", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - ipvs: ensure inner headers in ICMP errors are in headroom", "", " * CVE-2026-72320", " - netfilter: nft_lookup: fix catchall element handling with inverted", " lookups", "", " * CVE-2026-72322", " - ipv6: mcast: Fix potential UAF in MLD delayed work", "", " * CVE-2026-72323", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", "", " * CVE-2026-64541", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", "", " * CVE-2026-72339", " - qede: fix off-by-one in BD ring consumption on build_skb failure", "", " * CVE-2026-72348", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", "", " * CVE-2026-72351", " - gue: validate REMCSUM private option length", "", " * CVE-2026-72366", " - netfs: Fix netfs_create_write_req() to handle async cache object", " creation", "", " * CVE-2026-72381", " - ksmbd: fix use-after-free of fp->owner.name in durable handle owner", " check", "", " * CVE-2026-72393", " - eth: fbnic: don't cache shinfo across skb realloc", "", " * CVE-2026-72398", " - sctp: add INIT verification after cookie unpacking", "", " * CVE-2026-72399", " - net: enetc: check the number of BDs needed for xdp_frame", "", " * CVE-2026-64530", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", "", " * CVE-2026-72422", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", "", " * CVE-2026-72429", " - ipv6: ioam: fix type confusion of dst_entry", "", " * CVE-2026-72436", " - netfilter: ipset: Fix data race between add and dump in all hash types", " - netfilter: ipset: annotate \"pos\" for concurrent readers/writers", " - netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash", " types", "", " * CVE-2026-72451", " - xfrm: Fix xfrm state cache insertion race", "", " * CVE-2026-72466", " - xprtrdma: Fix bcall rep leak and unbounded peek", "", " * CVE-2026-72472", " - nfs: use nfsi->rwsem to protect traversal of the file lock list", "", " * CVE-2026-72473", " - xprtrdma: Avoid 250 ms delay on backlog wakeup", " - xprtrdma: Close lost-wakeup race in xprt_rdma_alloc_slot", " - xprtrdma: Post receive buffers after RPC completion", " - xprtrdma: Use sendctx DMA state for Send signaling", " - xprtrdma: Decouple req recycling from RPC completion", "", " * CVE-2026-72491", " - net/9p: fix race condition on rdma->state in trans_rdma.c", "", " * CVE-2026-72495 // CVE-2026-72501", " - RDMA/bnxt_re: Move the UAPI methods to a dedicated file", "", " * CVE-2026-74255", " - tipc: fix UAF in tipc_l2_send_msg()", "", " * CVE-2026-74267", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", "", " * CVE-2026-74268", " - tcp: clear sock_ops cb flags before force-closing a child socket", "", " * CVE-2026-74287", " - sctp: validate embedded address parameter length", "", " * CVE-2026-74310", " - vhost/net: complete zerocopy ubufs only once", "", " * CVE-2026-74345", " - RDMA/siw: Fix endpoint/socket association handling", "", " * CVE-2026-74361", " - nvme: fix FDP fdpcidx bounds check", "", " * CVE-2026-74376", " - md/raid10: reset read_slot when reusing r10bio for discard", "", " * CVE-2026-74384", " - nvme-multipath: fix flex array size in struct nvme_ns_head", "", " * CVE-2026-74394", " - RDMA/srpt: fix integer overflow in immediate data length check", "", " * CVE-2026-74398", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", "", " * CVE-2026-74401", " - dlm: fix add msg handle in send_queue ordered", "", " * CVE-2026-74406", " - vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().", "", " * CVE-2026-74427", " - afs: Fix netns teardown to cancel the preallocation charger", " - afs: Fix further netns teardown to cancel the preallocation charger", "", " * CVE-2026-74428", " - rxrpc: Fix double unlock in rxrpc_recvmsg()", "", " * CVE-2026-74433", " - rxrpc: Fix UAF in rxgk_issue_challenge()", "", " * CVE-2026-74434", " - rxrpc: Don't move a peeked OOB message onto the pending queue", "", " * CVE-2026-74436", " - rxrpc: serialize kernel accept preallocation with socket teardown", "", " * CVE-2026-64535", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", "", " * CVE-2026-74439", " - iommu/vt-d: Clear Present bit before tearing down scalable-mode context", " entry", "", " * CVE-2026-64534", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", "" ], "package": "linux", "version": "7.0.0-38.38", "urgency": "medium", "distributions": "resolute", "launchpad_bugs_fixed": [ 2166443, 2166356, 2165872, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165407, 2165040, 2161748, 2163508, 2163214, 2162904, 2162045, 2164967, 2160082, 2164504, 2156316, 2164716, 2164516, 2163375, 2162803, 2163062, 2132119, 2163293, 2160200, 2158858, 2162704, 2162695, 2164666, 2164666, 2163121 ], "author": "Edoardo Canepa ", "date": "Fri, 04 Sep 2026 10:31:15 +0300" } ], "notes": "linux-modules-7.0.0-38-generic version '7.0.0-38.38' (source package linux version '7.0.0-38.38') was added. linux-modules-7.0.0-38-generic version '7.0.0-38.38' has the same source package name, linux, as removed package linux-modules-7.0.0-34-generic. As such we can use the source package version of the removed package, '7.0.0-34.34', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-image-7.0.0-34-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "7.0.0-34.34", "version": "7.0.0-34.34" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-main-modules-zfs-7.0.0-34-generic", "from_version": { "source_package_name": "linux-main-signed", "source_package_version": "7.0.0-34.34", "version": "7.0.0-34.34" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-modules-7.0.0-34-generic", "from_version": { "source_package_name": "linux", "source_package_version": "7.0.0-34.34", "version": "7.0.0-34.34" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "notes": "Changelog diff for Ubuntu 26.04 resolute image from daily image serial 20260927 to 20261002", "from_series": "resolute", "to_series": "resolute", "from_serial": "20260927", "to_serial": "20261002", "from_manifest_filename": "daily_manifest.previous", "to_manifest_filename": "manifest.current" }