{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-headers-7.0.0-34-generic", "linux-image-7.0.0-34-generic", "linux-modules-7.0.0-34-generic", "linux-riscv-7.0-headers-7.0.0-34", "linux-riscv-7.0-tools-7.0.0-34", "linux-tools-7.0.0-34-generic" ], "removed": [ "linux-headers-7.0.0-31-generic", "linux-image-7.0.0-31-generic", "linux-modules-7.0.0-31-generic", "linux-riscv-7.0-headers-7.0.0-31", "linux-riscv-7.0-tools-7.0.0-31", "linux-tools-7.0.0-31-generic" ], "diff": [ "apparmor", "curl", "dmidecode", "gir1.2-glib-2.0:riscv64", "krb5-locales", "libaom3:riscv64", "libapparmor1:riscv64", "libaudit-common", "libaudit1:riscv64", "libcurl3t64-gnutls:riscv64", "libcurl4t64:riscv64", "libexpat1:riscv64", "libglib2.0-0t64:riscv64", "libglib2.0-bin", "libglib2.0-data", "libgssapi-krb5-2:riscv64", "libisns0t64:riscv64", "libk5crypto3:riscv64", "libkrb5-3:riscv64", "libkrb5support0:riscv64", "libnetplan1:riscv64", "libpcap0.8t64:riscv64", "libperl5.38t64:riscv64", "libpolkit-agent-1-0:riscv64", "libpolkit-gobject-1-0:riscv64", "libsqlite3-0:riscv64", "libxml2:riscv64", "linux-headers-generic", "linux-headers-virtual", "linux-image-virtual", "linux-libc-dev:riscv64", "linux-tools-common", "linux-virtual", "netplan-generator", "netplan.io", "perl", "perl-base", "perl-modules-5.38", "polkitd", "python3-netplan", "rsyslog", "sudo" ] } }, "diff": { "deb": [ { "name": "apparmor", "from_version": { "source_package_name": "apparmor", "source_package_version": "4.0.1really4.0.1-0ubuntu0.24.04.7", "version": "4.0.1really4.0.1-0ubuntu0.24.04.7" }, "to_version": { "source_package_name": "apparmor", "source_package_version": "4.0.1really4.0.1-0ubuntu0.24.04.8", "version": "4.0.1really4.0.1-0ubuntu0.24.04.8" }, "cves": [], "launchpad_bugs_fixed": [ 2162134 ], "changes": [ { "cves": [], "log": [ "", " * Don't add mediation classes to unconfined profiles (LP: #2162134)", " - d/p/u/parser-dont-add-mediation-classes-to-unconfined.patch", "" ], "package": "apparmor", "version": "4.0.1really4.0.1-0ubuntu0.24.04.8", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2162134 ], "author": "Taichi Maeda ", "date": "Fri, 31 Jul 2026 12:50:22 +0900" } ], "notes": null, "is_version_downgrade": false }, { "name": "curl", "from_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.13", "version": "8.5.0-2ubuntu10.13" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.15", "version": "8.5.0-2ubuntu10.15" }, "cves": [ { "cve": "CVE-2026-13608", "url": "https://ubuntu.com/security/CVE-2026-13608", "cve_description": "A flaw in the libcurl SASL negotiation for LDAP authentication allows an incomplete handshake sequence to be misinterpreted as a successful cryptographic verification. An attacker executing a Man-in-the-Middle (MITM) attack can inject a premature or shortcut response that bypasses complete peer validation.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-18924", "url": "https://ubuntu.com/security/CVE-2026-18924", "cve_description": "A flaw in libcurl's handling of HTTP/2 Server Push streams, when the parent handle is set to share connections with other handles, can lead to use-after-free in the cleanup process.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-80230", "url": "https://ubuntu.com/security/CVE-2026-80230", "cve_description": "When `CURLOPT_PINNEDPUBLICKEY` is configured alongside options that disable standard peer verification (`CURLOPT_SSL_VERIFYPEER = 0` and `CURLOPT_SSL_VERIFYHOST = 0`), libcurl fails to enforce public key pinning on connections established without a presented server certificate. Bypassing the pinning check under these disabled-verification conditions allows unauthenticated connections to succeed when they should be rejected.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-82209", "url": "https://ubuntu.com/security/CVE-2026-82209", "cve_description": "When libpsl support is enabled, libcurl fails to enforce the Public Suffix List boundary check when processing a `Set-Cookie` header where the `Domain` attribute explicitly matches an origin host that is itself a public suffix (e.g., `Domain=co.uk` set by `co.uk`). Instead of coercing it into a strict host-only cookie, libcurl saves the cookie with wildcard domain scope (`.co.uk`). Consequently, the cookie is inappropriately included in subsequent outbound requests or HTTP redirects to arbitrary sibling subdomains under the same public suffix (e.g., `attacker.co.uk`).", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-8927", "url": "https://ubuntu.com/security/CVE-2026-8927", "cve_description": "When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent transfer routed through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended solely for `proxyA`.", "cve_priority": "medium", "cve_public_date": "2026-07-03 07:16:00 UTC" }, { "cve": "CVE-2026-6429", "url": "https://ubuntu.com/security/CVE-2026-6429", "cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-8286", "url": "https://ubuntu.com/security/CVE-2026-8286", "cve_description": "A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not.", "cve_priority": "low", "cve_public_date": "2026-07-03 07:16:00 UTC" }, { "cve": "CVE-2026-8458", "url": "https://ubuntu.com/security/CVE-2026-8458", "cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different \"services\". libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.", "cve_priority": "low", "cve_public_date": "2026-07-03 07:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-13608", "url": "https://ubuntu.com/security/CVE-2026-13608", "cve_description": "A flaw in the libcurl SASL negotiation for LDAP authentication allows an incomplete handshake sequence to be misinterpreted as a successful cryptographic verification. An attacker executing a Man-in-the-Middle (MITM) attack can inject a premature or shortcut response that bypasses complete peer validation.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-18924", "url": "https://ubuntu.com/security/CVE-2026-18924", "cve_description": "A flaw in libcurl's handling of HTTP/2 Server Push streams, when the parent handle is set to share connections with other handles, can lead to use-after-free in the cleanup process.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-80230", "url": "https://ubuntu.com/security/CVE-2026-80230", "cve_description": "When `CURLOPT_PINNEDPUBLICKEY` is configured alongside options that disable standard peer verification (`CURLOPT_SSL_VERIFYPEER = 0` and `CURLOPT_SSL_VERIFYHOST = 0`), libcurl fails to enforce public key pinning on connections established without a presented server certificate. Bypassing the pinning check under these disabled-verification conditions allows unauthenticated connections to succeed when they should be rejected.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-82209", "url": "https://ubuntu.com/security/CVE-2026-82209", "cve_description": "When libpsl support is enabled, libcurl fails to enforce the Public Suffix List boundary check when processing a `Set-Cookie` header where the `Domain` attribute explicitly matches an origin host that is itself a public suffix (e.g., `Domain=co.uk` set by `co.uk`). Instead of coercing it into a strict host-only cookie, libcurl saves the cookie with wildcard domain scope (`.co.uk`). Consequently, the cookie is inappropriately included in subsequent outbound requests or HTTP redirects to arbitrary sibling subdomains under the same public suffix (e.g., `attacker.co.uk`).", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-8927", "url": "https://ubuntu.com/security/CVE-2026-8927", "cve_description": "When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent transfer routed through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended solely for `proxyA`.", "cve_priority": "medium", "cve_public_date": "2026-07-03 07:16:00 UTC" }, { "cve": "CVE-2026-6429", "url": "https://ubuntu.com/security/CVE-2026-6429", "cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-8286", "url": "https://ubuntu.com/security/CVE-2026-8286", "cve_description": "A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not.", "cve_priority": "low", "cve_public_date": "2026-07-03 07:16:00 UTC" }, { "cve": "CVE-2026-8458", "url": "https://ubuntu.com/security/CVE-2026-8458", "cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different \"services\". libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.", "cve_priority": "low", "cve_public_date": "2026-07-03 07:16:00 UTC" } ], "log": [ "", " [ Charles Cochran ]", " * SECURITY UPDATE: Authentication bypass in LDAP SASL negotiation.", " - debian/patches/CVE-2026-13608.patch: openldap: handle", " Curl_sasl_continue() returns better in lib/openldap.c.", " - CVE-2026-13608", " * SECURITY UPDATE: Use after free in HTTP/2 server push.", " - debian/patches/CVE-2026-18924.patch: make server push transfers", " inherit share from parent in lib/http2.c.", " - CVE-2026-18924", " * SECURITY UPDATE: Public key pinning bypass.", " - debian/patches/CVE-2026-80230.patch: require server cert if public", " key pinned in lib/vtls/openssl.c.", " - CVE-2026-80230", " * SECURITY UPDATE: Cookie injection for public suffix domains.", " - debian/patches/CVE-2026-82209.patch: ensure cookies set for an exact", " PSL domain are host-only in lib/cookie.c, tests/data/Makefile.inc,", " tests/data/test1136, tests/data/test2318.", " - CVE-2026-82209", "", " [ Kyle Kernick]", " * SECURITY REGRESSION: checksrc errors and failing test case for", " CVE-2026-8927 (LP #2167779)", " - debian/patches/CVE-2026-6429.patch: Fix indentation to fix", " autopkgtests in lib/transfer.c.", " - debian/patches/CVE-2026-8286.patch: Wrap long line to fix", " autopkgtests in lib/url.c.", " - debian/patches/CVE-2026-8458.patch: Wrap long lines and fix", " indentation to fix autopkgtests in lib/curl_sasl.c.", " - debian/patches/CVE-2026-8927.patch: Fix failing test", "" ], "package": "curl", "version": "8.5.0-2ubuntu10.15", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Charles Cochran ", "date": "Fri, 18 Sep 2026 11:45:57 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "dmidecode", "from_version": { "source_package_name": "dmidecode", "source_package_version": "3.5-3ubuntu0.1", "version": "3.5-3ubuntu0.1" }, "to_version": { "source_package_name": "dmidecode", "source_package_version": "3.5-3ubuntu0.2", "version": "3.5-3ubuntu0.2" }, "cves": [], "launchpad_bugs_fixed": [ 2148318 ], "changes": [ { "cves": [], "log": [ "", " * Display slot ID for more slot types and EDSFF (LP: #2148318)", " - d/p/lp-2148318-1-dmidecode-Display-slot-information-for-EDSFF.patch", " - d/p/lp-2148318-2-dmidecode-Display-the-slot-ID-for-more-slot-types.patch", "" ], "package": "dmidecode", "version": "3.5-3ubuntu0.2", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2148318 ], "author": "Mitchell Augustin ", "date": "Thu, 02 Jul 2026 11:58:32 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "gir1.2-glib-2.0:riscv64", "from_version": { "source_package_name": "glib2.0", "source_package_version": "2.80.0-6ubuntu3.8", "version": "2.80.0-6ubuntu3.8" }, "to_version": { "source_package_name": "glib2.0", "source_package_version": "2.80.0-6ubuntu3.9", "version": "2.80.0-6ubuntu3.9" }, "cves": [ { "cve": "CVE-2026-58010", "url": "https://ubuntu.com/security/CVE-2026-58010", "cve_description": "A flaw was found in GLib. An off-by-one error can occur in the gvs_tuple_is_normal function in the glib/gvariant-serialiser.c file when doing an alignment padding check because the bounds check uses > instead of >=, causing an out-of-bounds read of only 1 byte. This issue can cause a minor information disclosure of 1 byte and a denial of service when the out-of-bounds read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58011", "url": "https://ubuntu.com/security/CVE-2026-58011", "cve_description": "A flaw was found in GLib. An out-of-bounds read of only 2 bytes can occur in the g_date_time_get_ymd function in the glib/gdatetime.c file when an invalid GDateTime object produced by the g_date_time_add_full function is processed. This flaw can corrupt the date output and potentially cause logic errors that may lead to a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58012", "url": "https://ubuntu.com/security/CVE-2026-58012", "cve_description": "A flaw was found in GLib. A buffer over-read can occur in the g_regex_replace function when used with the `G_REGEX_RAW` compile flag and case-change replacement escapes because the string_append function processes matched substrings using UTF-8 functions that assume valid UTF-8 input, even when the string is treated as raw bytes. This vulnerability can cause a minor information disclosure of 1-5 bytes and a denial of service when the buffer over-read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58013", "url": "https://ubuntu.com/security/CVE-2026-58013", "cve_description": "A flaw was found in GLib. A buffer over-read can occur in g_io_channel_read_line_backend() in the giochannel.c file when a custom line terminator with a length greater than one is set, causing memcmp to read past the GString buffer. This vulnerability can cause a minor information disclosure of 7 bytes or a denial of service when the buffer over-read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58014", "url": "https://ubuntu.com/security/CVE-2026-58014", "cve_description": "A flaw was found in GLib. An off-by-one error can occur in the g_key_file_get_locale_string_list function in the gkeyfile.c file when loading a key file with an empty value. This flaw can cause an out-of-bounds access of 1 byte or a denial of service when the out-of-bounds access crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58015", "url": "https://ubuntu.com/security/CVE-2026-58015", "cve_description": "A flaw was found in GLib. The D-Bus client-side implementation of the DBUS_COOKIE_SHA1 SASL authentication mechanism does not validate the cookie_context parameter received from the server. A malicious D-Bus server can supply a cookie_context containing path traversal sequences, causing the client to read an arbitrary file and exfiltrate sensitive data by verifying guessed file contents against a generated hash.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58016", "url": "https://ubuntu.com/security/CVE-2026-58016", "cve_description": "A flaw was found in GLib. A state confusion issue exists in g_dbus_node_info_new_for_xml() in the gio/gdbusintrospection.c file when processing malformed D-Bus introspection XML, specifically with a `node` element nested within other elements like `method`, `signal`, `property` or `arg`. This issue can cause an unsigned integer overflow and lead to an out-of-bounds read, resulting in a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-15588", "url": "https://ubuntu.com/security/CVE-2026-15588", "cve_description": "A denial-of-service and resource exhaustion vulnerability exists within the `GDBus` component of GLib. The `gdbusauth` authentication mechanism fails to enforce proper length limitations on data lines read from a client. An unauthenticated local or remote attacker can exploit this lack of input validation by sending excessively long streams of data, causing the application to consume massive amounts of system memory and CPU, potentially leading to a crash or system hang.", "cve_priority": "medium", "cve_public_date": "2026-07-20 12:17:00 UTC" }, { "cve": "CVE-2026-16118", "url": "https://ubuntu.com/security/CVE-2026-16118", "cve_description": "A flaw was found in xdgmime. A heap-based buffer overflow can be triggered in _xdg_mime_magic_parse_magic_line() in the xdgmimemagic.c file on little-endian systems when an attacker-controlled MIME magic file in a user-writable XDG data location (e.g., in the $XDG_DATA_HOME/mime/magic path) is parsed by an application performing MIME type detection (e.g., via g_content_type_guess()). When performing byte-swap, incorrect pointer arithmetic on the write side causes an out-of-bounds write of 2 bytes, resulting in an application crash or memory corruption.", "cve_priority": "medium", "cve_public_date": "2026-07-17 20:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-58010", "url": "https://ubuntu.com/security/CVE-2026-58010", "cve_description": "A flaw was found in GLib. An off-by-one error can occur in the gvs_tuple_is_normal function in the glib/gvariant-serialiser.c file when doing an alignment padding check because the bounds check uses > instead of >=, causing an out-of-bounds read of only 1 byte. This issue can cause a minor information disclosure of 1 byte and a denial of service when the out-of-bounds read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58011", "url": "https://ubuntu.com/security/CVE-2026-58011", "cve_description": "A flaw was found in GLib. An out-of-bounds read of only 2 bytes can occur in the g_date_time_get_ymd function in the glib/gdatetime.c file when an invalid GDateTime object produced by the g_date_time_add_full function is processed. This flaw can corrupt the date output and potentially cause logic errors that may lead to a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58012", "url": "https://ubuntu.com/security/CVE-2026-58012", "cve_description": "A flaw was found in GLib. A buffer over-read can occur in the g_regex_replace function when used with the `G_REGEX_RAW` compile flag and case-change replacement escapes because the string_append function processes matched substrings using UTF-8 functions that assume valid UTF-8 input, even when the string is treated as raw bytes. This vulnerability can cause a minor information disclosure of 1-5 bytes and a denial of service when the buffer over-read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58013", "url": "https://ubuntu.com/security/CVE-2026-58013", "cve_description": "A flaw was found in GLib. A buffer over-read can occur in g_io_channel_read_line_backend() in the giochannel.c file when a custom line terminator with a length greater than one is set, causing memcmp to read past the GString buffer. This vulnerability can cause a minor information disclosure of 7 bytes or a denial of service when the buffer over-read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58014", "url": "https://ubuntu.com/security/CVE-2026-58014", "cve_description": "A flaw was found in GLib. An off-by-one error can occur in the g_key_file_get_locale_string_list function in the gkeyfile.c file when loading a key file with an empty value. This flaw can cause an out-of-bounds access of 1 byte or a denial of service when the out-of-bounds access crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58015", "url": "https://ubuntu.com/security/CVE-2026-58015", "cve_description": "A flaw was found in GLib. The D-Bus client-side implementation of the DBUS_COOKIE_SHA1 SASL authentication mechanism does not validate the cookie_context parameter received from the server. A malicious D-Bus server can supply a cookie_context containing path traversal sequences, causing the client to read an arbitrary file and exfiltrate sensitive data by verifying guessed file contents against a generated hash.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58016", "url": "https://ubuntu.com/security/CVE-2026-58016", "cve_description": "A flaw was found in GLib. A state confusion issue exists in g_dbus_node_info_new_for_xml() in the gio/gdbusintrospection.c file when processing malformed D-Bus introspection XML, specifically with a `node` element nested within other elements like `method`, `signal`, `property` or `arg`. This issue can cause an unsigned integer overflow and lead to an out-of-bounds read, resulting in a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-15588", "url": "https://ubuntu.com/security/CVE-2026-15588", "cve_description": "A denial-of-service and resource exhaustion vulnerability exists within the `GDBus` component of GLib. The `gdbusauth` authentication mechanism fails to enforce proper length limitations on data lines read from a client. An unauthenticated local or remote attacker can exploit this lack of input validation by sending excessively long streams of data, causing the application to consume massive amounts of system memory and CPU, potentially leading to a crash or system hang.", "cve_priority": "medium", "cve_public_date": "2026-07-20 12:17:00 UTC" }, { "cve": "CVE-2026-16118", "url": "https://ubuntu.com/security/CVE-2026-16118", "cve_description": "A flaw was found in xdgmime. A heap-based buffer overflow can be triggered in _xdg_mime_magic_parse_magic_line() in the xdgmimemagic.c file on little-endian systems when an attacker-controlled MIME magic file in a user-writable XDG data location (e.g., in the $XDG_DATA_HOME/mime/magic path) is parsed by an application performing MIME type detection (e.g., via g_content_type_guess()). When performing byte-swap, incorrect pointer arithmetic on the write side causes an out-of-bounds write of 2 bytes, resulting in an application crash or memory corruption.", "cve_priority": "medium", "cve_public_date": "2026-07-17 20:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: off-by-one OOB read in GVariant serialiser", " - debian/patches/CVE-2026-58010.patch: fix bounds check to use >= instead", " of > in gvs_tuple_is_normal() in glib/gvariant-serialiser.c.", " - CVE-2026-58010", " * SECURITY UPDATE: OOB read in GDateTime", " - debian/patches/CVE-2026-58011.patch: add missing range validation to", " g_date_time_add_full() in glib/gdatetime.c.", " - CVE-2026-58011", " * SECURITY UPDATE: buffer over-read in g_regex_replace", " - debian/patches/CVE-2026-58012.patch: fix case-change substitution", " handling with G_REGEX_RAW in glib/gregex.c.", " - CVE-2026-58012", " * SECURITY UPDATE: buffer over-read in GIOChannel", " - debian/patches/CVE-2026-58013.patch: add length check before memcmp", " in g_io_channel_read_line_backend() in glib/giochannel.c.", " - CVE-2026-58013", " * SECURITY UPDATE: off-by-one heap under-read in GKeyFile", " - debian/patches/CVE-2026-58014.patch: add len > 0 check before", " accessing value[len-1] in g_key_file_get_locale_string_list() in", " glib/gkeyfile.c.", " - CVE-2026-58014", " * SECURITY UPDATE: path traversal in DBUS_COOKIE_SHA1 auth", " - debian/patches/CVE-2026-58015.patch: validate cookie_context parameter", " to prevent path traversal in gio/gdbusauthmechanismsha1.c.", " - CVE-2026-58015", " * SECURITY UPDATE: state confusion in D-Bus introspection XML parser", " - debian/patches/CVE-2026-58016.patch: fix node element nesting check", " and add assertions in gio/gdbusintrospection.c.", " - CVE-2026-58016", " * SECURITY UPDATE: resource exhaustion in GDBus authentication", " - debian/patches/CVE-2026-15588.patch: limit length of lines read from", " client in gio/gdbusauth.c.", " - CVE-2026-15588", " * SECURITY UPDATE: heap buffer overflow in xdgmime", " - debian/patches/CVE-2026-16118.patch: fix pointer arithmetic in", " byte-swap routine in gio/xdgmime/xdgmimemagic.c.", " - CVE-2026-16118", "" ], "package": "glib2.0", "version": "2.80.0-6ubuntu3.9", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Leonidas Da Silva Barbosa ", "date": "Tue, 08 Sep 2026 14:07:47 -0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "krb5-locales", "from_version": { "source_package_name": "krb5", "source_package_version": "1.20.1-6ubuntu2.8", "version": "1.20.1-6ubuntu2.8" }, "to_version": { "source_package_name": "krb5", "source_package_version": "1.20.1-6ubuntu2.10", "version": "1.20.1-6ubuntu2.10" }, "cves": [], "launchpad_bugs_fixed": [ 2162744 ], "changes": [ { "cves": [], "log": [ "", " * d/t/control: Don't run kinit-pwexpire on 32-bit architectures", " The test verifies correct behavior for dates in the far future", " (~70 years after the time of test), which krb5's date parser", " only accepts on 64 bit arches.", "" ], "package": "krb5", "version": "1.20.1-6ubuntu2.10", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Grayson Wolf ", "date": "Thu, 20 Aug 2026 09:07:25 -0400" }, { "cves": [], "log": [ "", " * d/p/lp2162744-ts-interval.patch: Add ts_interval to accomodate", " for large time intervals (LP: #2162744)", " * d/t/kinit-pwexpire: Add test that long PW expiry dates", " do not overflow and produce wrong messages.", "" ], "package": "krb5", "version": "1.20.1-6ubuntu2.9", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2162744 ], "author": "Grayson Wolf ", "date": "Tue, 11 Aug 2026 17:30:54 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libaom3:riscv64", "from_version": { "source_package_name": "aom", "source_package_version": "3.8.2-2ubuntu0.1", "version": "3.8.2-2ubuntu0.1" }, "to_version": { "source_package_name": "aom", "source_package_version": "3.8.2-2ubuntu0.2", "version": "3.8.2-2ubuntu0.2" }, "cves": [ { "cve": "CVE-2026-56208", "url": "https://ubuntu.com/security/CVE-2026-56208", "cve_description": "A heap buffer overflow vulnerability was found in libaom, the reference AV1 codec implementation. A flaw in the AV1 encoder's Look-Ahead Processing (LAP) mode causes the first-pass stats ring buffer wrap-around guard to be bypassed when g_lag_in_frames is set to 1 or higher. This results in a 232-byte out-of-bounds write on every encoded frame after the second, corrupting adjacent heap objects. An attacker who can influence encoder configuration in a transcoding service or WebRTC session could exploit this to cause a denial of service (process crash) or potentially achieve code execution.", "cve_priority": "medium", "cve_public_date": "2026-06-19 17:16:00 UTC" }, { "cve": "CVE-2026-56209", "url": "https://ubuntu.com/security/CVE-2026-56209", "cve_description": "An arbitrary address write vulnerability was found in libaom, the reference AV1 codec implementation. A missing bounds check in the SVC (Scalable Video Coding) layer ID control function allows an attacker to inject an arbitrary pointer into the cyclic refresh map field via crafted image pixel values. The encoder then writes approximately 1,200 bytes at the attacker-controlled address. This is fully deterministic and does not require a separate information leak. An attacker who can supply frames to a network-facing libaom encoder with SVC enabled could exploit this for denial of service or potential code execution.", "cve_priority": "medium", "cve_public_date": "2026-06-19 17:16:00 UTC" }, { "cve": "CVE-2026-56210", "url": "https://ubuntu.com/security/CVE-2026-56210", "cve_description": "A heap-buffer-overflow read vulnerability was found in libaom, the reference AV1 codec implementation. A missing bounds check in the SVC (Scalable Video Coding) layer ID control function allows setting a spatial_layer_id exceeding the configured number of layers. This causes an out-of-bounds heap read of approximately 40,728 bytes when computing a layer context array index. An attacker who can influence SVC encoder parameters in a network-facing service could exploit this for information disclosure (heap content leak) or denial of service (segmentation fault from hitting unmapped memory).", "cve_priority": "medium", "cve_public_date": "2026-06-19 17:16:00 UTC" }, { "cve": "CVE-2026-56211", "url": "https://ubuntu.com/security/CVE-2026-56211", "cve_description": "A remote code execution vulnerability was found in libaom, the reference AV1 codec implementation. Insufficient bounds validation in the AV1 encoder's SVC (Scalable Video Coding) layer ID control allows an attacker to supply crafted video frame pixels that overlap with internal encoder layer context structures. In fork-based video processing services, an attacker can use this to hijack the cyclic refresh map pointer, brute-force the process base address via a crash oracle, and redirect control flow to achieve arbitrary command execution. Exploitation requires the target service to use libaom with SVC encoding enabled and accept attacker-supplied video frames.", "cve_priority": "medium", "cve_public_date": "2026-06-19 17:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-56208", "url": "https://ubuntu.com/security/CVE-2026-56208", "cve_description": "A heap buffer overflow vulnerability was found in libaom, the reference AV1 codec implementation. A flaw in the AV1 encoder's Look-Ahead Processing (LAP) mode causes the first-pass stats ring buffer wrap-around guard to be bypassed when g_lag_in_frames is set to 1 or higher. This results in a 232-byte out-of-bounds write on every encoded frame after the second, corrupting adjacent heap objects. An attacker who can influence encoder configuration in a transcoding service or WebRTC session could exploit this to cause a denial of service (process crash) or potentially achieve code execution.", "cve_priority": "medium", "cve_public_date": "2026-06-19 17:16:00 UTC" }, { "cve": "CVE-2026-56209", "url": "https://ubuntu.com/security/CVE-2026-56209", "cve_description": "An arbitrary address write vulnerability was found in libaom, the reference AV1 codec implementation. A missing bounds check in the SVC (Scalable Video Coding) layer ID control function allows an attacker to inject an arbitrary pointer into the cyclic refresh map field via crafted image pixel values. The encoder then writes approximately 1,200 bytes at the attacker-controlled address. This is fully deterministic and does not require a separate information leak. An attacker who can supply frames to a network-facing libaom encoder with SVC enabled could exploit this for denial of service or potential code execution.", "cve_priority": "medium", "cve_public_date": "2026-06-19 17:16:00 UTC" }, { "cve": "CVE-2026-56210", "url": "https://ubuntu.com/security/CVE-2026-56210", "cve_description": "A heap-buffer-overflow read vulnerability was found in libaom, the reference AV1 codec implementation. A missing bounds check in the SVC (Scalable Video Coding) layer ID control function allows setting a spatial_layer_id exceeding the configured number of layers. This causes an out-of-bounds heap read of approximately 40,728 bytes when computing a layer context array index. An attacker who can influence SVC encoder parameters in a network-facing service could exploit this for information disclosure (heap content leak) or denial of service (segmentation fault from hitting unmapped memory).", "cve_priority": "medium", "cve_public_date": "2026-06-19 17:16:00 UTC" }, { "cve": "CVE-2026-56211", "url": "https://ubuntu.com/security/CVE-2026-56211", "cve_description": "A remote code execution vulnerability was found in libaom, the reference AV1 codec implementation. Insufficient bounds validation in the AV1 encoder's SVC (Scalable Video Coding) layer ID control allows an attacker to supply crafted video frame pixels that overlap with internal encoder layer context structures. In fork-based video processing services, an attacker can use this to hijack the cyclic refresh map pointer, brute-force the process base address via a crash oracle, and redirect control flow to achieve arbitrary command execution. Exploitation requires the target service to use libaom with SVC encoding enabled and accept attacker-supplied video frames.", "cve_priority": "medium", "cve_public_date": "2026-06-19 17:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Heap buffer overflow in LAP mode", " - debian/patches/CVE-2026-56208.patch: handle buffer pointer in LAP", " mode to avoid buffer overflow in av1/encoder/encoder.h,", " av1/encoder/firstpass.c, av1/encoder/pass2_strategy.c,", " test/encode_api_test.cc.", " - CVE-2026-56208", " * SECURITY UPDATE: Missing bounds check on SVC layer ID controls", " - debian/patches/CVE-2026-56209_56210_56211.patch: check for invalid", " parameters for SVC layer ID setting in aom/aomcx.h,", " av1/av1_cx_iface.c, test/encode_api_test.cc.", " - CVE-2026-56209", " - CVE-2026-56210", " - CVE-2026-56211", "" ], "package": "aom", "version": "3.8.2-2ubuntu0.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Allen Huang ", "date": "Mon, 14 Sep 2026 17:15:00 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "libapparmor1:riscv64", "from_version": { "source_package_name": "apparmor", "source_package_version": "4.0.1really4.0.1-0ubuntu0.24.04.7", "version": "4.0.1really4.0.1-0ubuntu0.24.04.7" }, "to_version": { "source_package_name": "apparmor", "source_package_version": "4.0.1really4.0.1-0ubuntu0.24.04.8", "version": "4.0.1really4.0.1-0ubuntu0.24.04.8" }, "cves": [], "launchpad_bugs_fixed": [ 2162134 ], "changes": [ { "cves": [], "log": [ "", " * Don't add mediation classes to unconfined profiles (LP: #2162134)", " - d/p/u/parser-dont-add-mediation-classes-to-unconfined.patch", "" ], "package": "apparmor", "version": "4.0.1really4.0.1-0ubuntu0.24.04.8", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2162134 ], "author": "Taichi Maeda ", "date": "Fri, 31 Jul 2026 12:50:22 +0900" } ], "notes": null, "is_version_downgrade": false }, { "name": "libaudit-common", "from_version": { "source_package_name": "audit", "source_package_version": "1:3.1.2-2.1build1.1", "version": "1:3.1.2-2.1build1.1" }, "to_version": { "source_package_name": "audit", "source_package_version": "1:3.1.2-2.1ubuntu0.1", "version": "1:3.1.2-2.1ubuntu0.1" }, "cves": [], "launchpad_bugs_fixed": [ 1117804 ], "changes": [ { "cves": [], "log": [ "", " * Fix AppArmor AVC events not appearing in `ausearch` (LP: #1117804)", " - d/p/lp1117804-audit-ausearch-do-not-require-tclass.patch", "" ], "package": "audit", "version": "1:3.1.2-2.1ubuntu0.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1117804 ], "author": "Alex Ramírez ", "date": "Mon, 13 Jul 2026 20:10:31 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "libaudit1:riscv64", "from_version": { "source_package_name": "audit", "source_package_version": "1:3.1.2-2.1build1.1", "version": "1:3.1.2-2.1build1.1" }, "to_version": { "source_package_name": "audit", "source_package_version": "1:3.1.2-2.1ubuntu0.1", "version": "1:3.1.2-2.1ubuntu0.1" }, "cves": [], "launchpad_bugs_fixed": [ 1117804 ], "changes": [ { "cves": [], "log": [ "", " * Fix AppArmor AVC events not appearing in `ausearch` (LP: #1117804)", " - d/p/lp1117804-audit-ausearch-do-not-require-tclass.patch", "" ], "package": "audit", "version": "1:3.1.2-2.1ubuntu0.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1117804 ], "author": "Alex Ramírez ", "date": "Mon, 13 Jul 2026 20:10:31 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "libcurl3t64-gnutls:riscv64", "from_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.13", "version": "8.5.0-2ubuntu10.13" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.15", "version": "8.5.0-2ubuntu10.15" }, "cves": [ { "cve": "CVE-2026-13608", "url": "https://ubuntu.com/security/CVE-2026-13608", "cve_description": "A flaw in the libcurl SASL negotiation for LDAP authentication allows an incomplete handshake sequence to be misinterpreted as a successful cryptographic verification. An attacker executing a Man-in-the-Middle (MITM) attack can inject a premature or shortcut response that bypasses complete peer validation.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-18924", "url": "https://ubuntu.com/security/CVE-2026-18924", "cve_description": "A flaw in libcurl's handling of HTTP/2 Server Push streams, when the parent handle is set to share connections with other handles, can lead to use-after-free in the cleanup process.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-80230", "url": "https://ubuntu.com/security/CVE-2026-80230", "cve_description": "When `CURLOPT_PINNEDPUBLICKEY` is configured alongside options that disable standard peer verification (`CURLOPT_SSL_VERIFYPEER = 0` and `CURLOPT_SSL_VERIFYHOST = 0`), libcurl fails to enforce public key pinning on connections established without a presented server certificate. Bypassing the pinning check under these disabled-verification conditions allows unauthenticated connections to succeed when they should be rejected.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-82209", "url": "https://ubuntu.com/security/CVE-2026-82209", "cve_description": "When libpsl support is enabled, libcurl fails to enforce the Public Suffix List boundary check when processing a `Set-Cookie` header where the `Domain` attribute explicitly matches an origin host that is itself a public suffix (e.g., `Domain=co.uk` set by `co.uk`). Instead of coercing it into a strict host-only cookie, libcurl saves the cookie with wildcard domain scope (`.co.uk`). Consequently, the cookie is inappropriately included in subsequent outbound requests or HTTP redirects to arbitrary sibling subdomains under the same public suffix (e.g., `attacker.co.uk`).", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-8927", "url": "https://ubuntu.com/security/CVE-2026-8927", "cve_description": "When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent transfer routed through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended solely for `proxyA`.", "cve_priority": "medium", "cve_public_date": "2026-07-03 07:16:00 UTC" }, { "cve": "CVE-2026-6429", "url": "https://ubuntu.com/security/CVE-2026-6429", "cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-8286", "url": "https://ubuntu.com/security/CVE-2026-8286", "cve_description": "A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not.", "cve_priority": "low", "cve_public_date": "2026-07-03 07:16:00 UTC" }, { "cve": "CVE-2026-8458", "url": "https://ubuntu.com/security/CVE-2026-8458", "cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different \"services\". libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.", "cve_priority": "low", "cve_public_date": "2026-07-03 07:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-13608", "url": "https://ubuntu.com/security/CVE-2026-13608", "cve_description": "A flaw in the libcurl SASL negotiation for LDAP authentication allows an incomplete handshake sequence to be misinterpreted as a successful cryptographic verification. An attacker executing a Man-in-the-Middle (MITM) attack can inject a premature or shortcut response that bypasses complete peer validation.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-18924", "url": "https://ubuntu.com/security/CVE-2026-18924", "cve_description": "A flaw in libcurl's handling of HTTP/2 Server Push streams, when the parent handle is set to share connections with other handles, can lead to use-after-free in the cleanup process.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-80230", "url": "https://ubuntu.com/security/CVE-2026-80230", "cve_description": "When `CURLOPT_PINNEDPUBLICKEY` is configured alongside options that disable standard peer verification (`CURLOPT_SSL_VERIFYPEER = 0` and `CURLOPT_SSL_VERIFYHOST = 0`), libcurl fails to enforce public key pinning on connections established without a presented server certificate. Bypassing the pinning check under these disabled-verification conditions allows unauthenticated connections to succeed when they should be rejected.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-82209", "url": "https://ubuntu.com/security/CVE-2026-82209", "cve_description": "When libpsl support is enabled, libcurl fails to enforce the Public Suffix List boundary check when processing a `Set-Cookie` header where the `Domain` attribute explicitly matches an origin host that is itself a public suffix (e.g., `Domain=co.uk` set by `co.uk`). Instead of coercing it into a strict host-only cookie, libcurl saves the cookie with wildcard domain scope (`.co.uk`). Consequently, the cookie is inappropriately included in subsequent outbound requests or HTTP redirects to arbitrary sibling subdomains under the same public suffix (e.g., `attacker.co.uk`).", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-8927", "url": "https://ubuntu.com/security/CVE-2026-8927", "cve_description": "When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent transfer routed through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended solely for `proxyA`.", "cve_priority": "medium", "cve_public_date": "2026-07-03 07:16:00 UTC" }, { "cve": "CVE-2026-6429", "url": "https://ubuntu.com/security/CVE-2026-6429", "cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-8286", "url": "https://ubuntu.com/security/CVE-2026-8286", "cve_description": "A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not.", "cve_priority": "low", "cve_public_date": "2026-07-03 07:16:00 UTC" }, { "cve": "CVE-2026-8458", "url": "https://ubuntu.com/security/CVE-2026-8458", "cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different \"services\". libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.", "cve_priority": "low", "cve_public_date": "2026-07-03 07:16:00 UTC" } ], "log": [ "", " [ Charles Cochran ]", " * SECURITY UPDATE: Authentication bypass in LDAP SASL negotiation.", " - debian/patches/CVE-2026-13608.patch: openldap: handle", " Curl_sasl_continue() returns better in lib/openldap.c.", " - CVE-2026-13608", " * SECURITY UPDATE: Use after free in HTTP/2 server push.", " - debian/patches/CVE-2026-18924.patch: make server push transfers", " inherit share from parent in lib/http2.c.", " - CVE-2026-18924", " * SECURITY UPDATE: Public key pinning bypass.", " - debian/patches/CVE-2026-80230.patch: require server cert if public", " key pinned in lib/vtls/openssl.c.", " - CVE-2026-80230", " * SECURITY UPDATE: Cookie injection for public suffix domains.", " - debian/patches/CVE-2026-82209.patch: ensure cookies set for an exact", " PSL domain are host-only in lib/cookie.c, tests/data/Makefile.inc,", " tests/data/test1136, tests/data/test2318.", " - CVE-2026-82209", "", " [ Kyle Kernick]", " * SECURITY REGRESSION: checksrc errors and failing test case for", " CVE-2026-8927 (LP #2167779)", " - debian/patches/CVE-2026-6429.patch: Fix indentation to fix", " autopkgtests in lib/transfer.c.", " - debian/patches/CVE-2026-8286.patch: Wrap long line to fix", " autopkgtests in lib/url.c.", " - debian/patches/CVE-2026-8458.patch: Wrap long lines and fix", " indentation to fix autopkgtests in lib/curl_sasl.c.", " - debian/patches/CVE-2026-8927.patch: Fix failing test", "" ], "package": "curl", "version": "8.5.0-2ubuntu10.15", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Charles Cochran ", "date": "Fri, 18 Sep 2026 11:45:57 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libcurl4t64:riscv64", "from_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.13", "version": "8.5.0-2ubuntu10.13" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.15", "version": "8.5.0-2ubuntu10.15" }, "cves": [ { "cve": "CVE-2026-13608", "url": "https://ubuntu.com/security/CVE-2026-13608", "cve_description": "A flaw in the libcurl SASL negotiation for LDAP authentication allows an incomplete handshake sequence to be misinterpreted as a successful cryptographic verification. An attacker executing a Man-in-the-Middle (MITM) attack can inject a premature or shortcut response that bypasses complete peer validation.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-18924", "url": "https://ubuntu.com/security/CVE-2026-18924", "cve_description": "A flaw in libcurl's handling of HTTP/2 Server Push streams, when the parent handle is set to share connections with other handles, can lead to use-after-free in the cleanup process.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-80230", "url": "https://ubuntu.com/security/CVE-2026-80230", "cve_description": "When `CURLOPT_PINNEDPUBLICKEY` is configured alongside options that disable standard peer verification (`CURLOPT_SSL_VERIFYPEER = 0` and `CURLOPT_SSL_VERIFYHOST = 0`), libcurl fails to enforce public key pinning on connections established without a presented server certificate. Bypassing the pinning check under these disabled-verification conditions allows unauthenticated connections to succeed when they should be rejected.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-82209", "url": "https://ubuntu.com/security/CVE-2026-82209", "cve_description": "When libpsl support is enabled, libcurl fails to enforce the Public Suffix List boundary check when processing a `Set-Cookie` header where the `Domain` attribute explicitly matches an origin host that is itself a public suffix (e.g., `Domain=co.uk` set by `co.uk`). Instead of coercing it into a strict host-only cookie, libcurl saves the cookie with wildcard domain scope (`.co.uk`). Consequently, the cookie is inappropriately included in subsequent outbound requests or HTTP redirects to arbitrary sibling subdomains under the same public suffix (e.g., `attacker.co.uk`).", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-8927", "url": "https://ubuntu.com/security/CVE-2026-8927", "cve_description": "When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent transfer routed through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended solely for `proxyA`.", "cve_priority": "medium", "cve_public_date": "2026-07-03 07:16:00 UTC" }, { "cve": "CVE-2026-6429", "url": "https://ubuntu.com/security/CVE-2026-6429", "cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-8286", "url": "https://ubuntu.com/security/CVE-2026-8286", "cve_description": "A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not.", "cve_priority": "low", "cve_public_date": "2026-07-03 07:16:00 UTC" }, { "cve": "CVE-2026-8458", "url": "https://ubuntu.com/security/CVE-2026-8458", "cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different \"services\". libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.", "cve_priority": "low", "cve_public_date": "2026-07-03 07:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-13608", "url": "https://ubuntu.com/security/CVE-2026-13608", "cve_description": "A flaw in the libcurl SASL negotiation for LDAP authentication allows an incomplete handshake sequence to be misinterpreted as a successful cryptographic verification. An attacker executing a Man-in-the-Middle (MITM) attack can inject a premature or shortcut response that bypasses complete peer validation.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-18924", "url": "https://ubuntu.com/security/CVE-2026-18924", "cve_description": "A flaw in libcurl's handling of HTTP/2 Server Push streams, when the parent handle is set to share connections with other handles, can lead to use-after-free in the cleanup process.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-80230", "url": "https://ubuntu.com/security/CVE-2026-80230", "cve_description": "When `CURLOPT_PINNEDPUBLICKEY` is configured alongside options that disable standard peer verification (`CURLOPT_SSL_VERIFYPEER = 0` and `CURLOPT_SSL_VERIFYHOST = 0`), libcurl fails to enforce public key pinning on connections established without a presented server certificate. Bypassing the pinning check under these disabled-verification conditions allows unauthenticated connections to succeed when they should be rejected.", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-82209", "url": "https://ubuntu.com/security/CVE-2026-82209", "cve_description": "When libpsl support is enabled, libcurl fails to enforce the Public Suffix List boundary check when processing a `Set-Cookie` header where the `Domain` attribute explicitly matches an origin host that is itself a public suffix (e.g., `Domain=co.uk` set by `co.uk`). Instead of coercing it into a strict host-only cookie, libcurl saves the cookie with wildcard domain scope (`.co.uk`). Consequently, the cookie is inappropriately included in subsequent outbound requests or HTTP redirects to arbitrary sibling subdomains under the same public suffix (e.g., `attacker.co.uk`).", "cve_priority": "medium", "cve_public_date": "2026-09-06 18:17:00 UTC" }, { "cve": "CVE-2026-8927", "url": "https://ubuntu.com/security/CVE-2026-8927", "cve_description": "When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent transfer routed through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended solely for `proxyA`.", "cve_priority": "medium", "cve_public_date": "2026-07-03 07:16:00 UTC" }, { "cve": "CVE-2026-6429", "url": "https://ubuntu.com/security/CVE-2026-6429", "cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-8286", "url": "https://ubuntu.com/security/CVE-2026-8286", "cve_description": "A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not.", "cve_priority": "low", "cve_public_date": "2026-07-03 07:16:00 UTC" }, { "cve": "CVE-2026-8458", "url": "https://ubuntu.com/security/CVE-2026-8458", "cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different \"services\". libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.", "cve_priority": "low", "cve_public_date": "2026-07-03 07:16:00 UTC" } ], "log": [ "", " [ Charles Cochran ]", " * SECURITY UPDATE: Authentication bypass in LDAP SASL negotiation.", " - debian/patches/CVE-2026-13608.patch: openldap: handle", " Curl_sasl_continue() returns better in lib/openldap.c.", " - CVE-2026-13608", " * SECURITY UPDATE: Use after free in HTTP/2 server push.", " - debian/patches/CVE-2026-18924.patch: make server push transfers", " inherit share from parent in lib/http2.c.", " - CVE-2026-18924", " * SECURITY UPDATE: Public key pinning bypass.", " - debian/patches/CVE-2026-80230.patch: require server cert if public", " key pinned in lib/vtls/openssl.c.", " - CVE-2026-80230", " * SECURITY UPDATE: Cookie injection for public suffix domains.", " - debian/patches/CVE-2026-82209.patch: ensure cookies set for an exact", " PSL domain are host-only in lib/cookie.c, tests/data/Makefile.inc,", " tests/data/test1136, tests/data/test2318.", " - CVE-2026-82209", "", " [ Kyle Kernick]", " * SECURITY REGRESSION: checksrc errors and failing test case for", " CVE-2026-8927 (LP #2167779)", " - debian/patches/CVE-2026-6429.patch: Fix indentation to fix", " autopkgtests in lib/transfer.c.", " - debian/patches/CVE-2026-8286.patch: Wrap long line to fix", " autopkgtests in lib/url.c.", " - debian/patches/CVE-2026-8458.patch: Wrap long lines and fix", " indentation to fix autopkgtests in lib/curl_sasl.c.", " - debian/patches/CVE-2026-8927.patch: Fix failing test", "" ], "package": "curl", "version": "8.5.0-2ubuntu10.15", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Charles Cochran ", "date": "Fri, 18 Sep 2026 11:45:57 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libexpat1:riscv64", "from_version": { "source_package_name": "expat", "source_package_version": "2.6.1-2ubuntu0.4", "version": "2.6.1-2ubuntu0.4" }, "to_version": { "source_package_name": "expat", "source_package_version": "2.6.1-2ubuntu0.6", "version": "2.6.1-2ubuntu0.6" }, "cves": [ { "cve": "CVE-2026-56410", "url": "https://ubuntu.com/security/CVE-2026-56410", "cve_description": "xmlwf in libexpat before 2.8.2 has an integer overflow in resolveSystemId.", "cve_priority": "medium", "cve_public_date": "2026-06-21 16:16:00 UTC" }, { "cve": "CVE-2026-56406", "url": "https://ubuntu.com/security/CVE-2026-56406", "cve_description": "libexpat before 2.8.2 has an integer overflow in XML_ParseBuffer because it lacked a check that was present in XML_Parse.", "cve_priority": "medium", "cve_public_date": "2026-06-21 16:16:00 UTC" }, { "cve": "CVE-2026-56409", "url": "https://ubuntu.com/security/CVE-2026-56409", "cve_description": "xmlwf in libexpat before 2.8.2 has an integer overflow for the output filename when -d outputDir is used.", "cve_priority": "medium", "cve_public_date": "2026-06-21 16:16:00 UTC" }, { "cve": "CVE-2026-56407", "url": "https://ubuntu.com/security/CVE-2026-56407", "cve_description": "libexpat before 2.8.2 has an integer overflow in doProlog that is related to storeEntityValue and entity textLen.", "cve_priority": "medium", "cve_public_date": "2026-06-21 16:16:00 UTC" }, { "cve": "CVE-2026-56411", "url": "https://ubuntu.com/security/CVE-2026-56411", "cve_description": "xmlwf in libexpat before 2.8.2 has an integer overflow in endDoctypeDecl via NOTATION declarations.", "cve_priority": "medium", "cve_public_date": "2026-06-21 17:16:00 UTC" }, { "cve": "CVE-2026-56131", "url": "https://ubuntu.com/security/CVE-2026-56131", "cve_description": "libexpat before 2.8.2 lacks handler call depth tracking for calls to XML_ResumeParser from within handlers in cases of a policy violation. Thus, a use-after-free can occur (similar to the CVE-2026-50219 situation).", "cve_priority": "medium", "cve_public_date": "2026-06-19 06:17:00 UTC" }, { "cve": "CVE-2026-56132", "url": "https://ubuntu.com/security/CVE-2026-56132", "cve_description": "In libexpat before 2.8.2, there is a heap-based buffer overflow in doProlog in xmlparse.c because scaffold backing array reallocation is mishandled when there is data-structure sharing across parsers.", "cve_priority": "medium", "cve_public_date": "2026-06-19 06:17:00 UTC" }, { "cve": "CVE-2026-72522", "url": "https://ubuntu.com/security/CVE-2026-72522", "cve_description": "libexpat before 2.8.3 has an out-of-bounds read and resultant infinite loop because low surrogates are treated the same as high surrogates during Unicode processing in the *_toUtf16 functions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 04:16:00 UTC" }, { "cve": "CVE-2026-66046", "url": "https://ubuntu.com/security/CVE-2026-66046", "cve_description": "Expat through 2.8.3 contains a denial of service vulnerability caused by quadratic algorithmic complexity in the storeAtts() function in xmlparse.c, where processing N specified attributes with non-normalized values triggers an O(N^2) linear scan of elementType->defaultAtts to determine CDATA status. A remote unauthenticated attacker can supply a single well-formed XML document of a few megabytes to an application parsing untrusted XML to cause excessive CPU consumption, resulting in denial of service without requiring authentication, external entity resolution, or non-default parser options.", "cve_priority": "medium", "cve_public_date": "2026-08-18 15:16:00 UTC" }, { "cve": "CVE-2026-76641", "url": "https://ubuntu.com/security/CVE-2026-76641", "cve_description": "Expat through 2.8.3 contains an out-of-bounds read vulnerability that allows attackers to trigger memory corruption by processing XML with external entity parsers created via XML_ExternalEntityParserCreate. A struct size mismatch between ELEMENT_TYPE members causes storeAtts to read the attIndex member past allocated memory boundaries, resulting in failure to normalize whitespace in non-CDATA attributes or a wild pointer dereference causing a segfault. This vulnerability was introduced by the fix for CVE-2026-66046.", "cve_priority": "medium", "cve_public_date": "2026-08-20 18:16:00 UTC" }, { "cve": "CVE-2026-76957", "url": "https://ubuntu.com/security/CVE-2026-76957", "cve_description": "libexpat before 2.8.4 lacks handler call depth tracking with custom encoding callbacks. Thus, a use-after-free can occur. NOTE: this is similar to CVE-2026-50219, CVE-2026-56131 and CVE-2026-56412.", "cve_priority": "medium", "cve_public_date": "2026-08-20 05:16:00 UTC" }, { "cve": "CVE-2025-59375", "url": "https://ubuntu.com/security/CVE-2025-59375", "cve_description": "libexpat in Expat before 2.7.2 allows attackers to trigger large dynamic memory allocations via a small document that is submitted for parsing.", "cve_priority": "medium", "cve_public_date": "2025-09-15 03:15:00 UTC" }, { "cve": "CVE-2026-32776", "url": "https://ubuntu.com/security/CVE-2026-32776", "cve_description": "libexpat before 2.7.5 allows a NULL pointer dereference with empty external parameter entity content.", "cve_priority": "medium", "cve_public_date": "2026-03-16 14:19:00 UTC" }, { "cve": "CVE-2026-32777", "url": "https://ubuntu.com/security/CVE-2026-32777", "cve_description": "libexpat before 2.7.5 allows an infinite loop while parsing DTD content.", "cve_priority": "medium", "cve_public_date": "2026-03-16 14:19:00 UTC" }, { "cve": "CVE-2026-32778", "url": "https://ubuntu.com/security/CVE-2026-32778", "cve_description": "libexpat before 2.7.5 allows a NULL pointer dereference in the function setContext on retry after an earlier ouf-of-memory condition.", "cve_priority": "medium", "cve_public_date": "2026-03-16 14:19:00 UTC" }, { "cve": "CVE-2026-45186", "url": "https://ubuntu.com/security/CVE-2026-45186", "cve_description": "In libexpat before 2.8.1, the computational complexity of attribute name collision checks allows a denial of service via moderately sized crafted XML input.", "cve_priority": "medium", "cve_public_date": "2026-05-10 07:16:00 UTC" }, { "cve": "CVE-2026-41080", "url": "https://ubuntu.com/security/CVE-2026-41080", "cve_description": "libexpat before 2.8.0 uses insufficient entropy, and thus hash flooding can occur via a crafted XML document.", "cve_priority": "medium", "cve_public_date": "2026-04-16 17:16:00 UTC" }, { "cve": "CVE-2026-56408", "url": "https://ubuntu.com/security/CVE-2026-56408", "cve_description": "libexpat before 2.8.2 has an integer overflow in copyString.", "cve_priority": "medium", "cve_public_date": "2026-06-21 16:16:00 UTC" }, { "cve": "CVE-2026-56403", "url": "https://ubuntu.com/security/CVE-2026-56403", "cve_description": "libexpat before 2.8.2 has an integer overflow in storeAtts.", "cve_priority": "medium", "cve_public_date": "2026-06-21 16:16:00 UTC" }, { "cve": "CVE-2026-50219", "url": "https://ubuntu.com/security/CVE-2026-50219", "cve_description": "libexpat before 2.8.2 lacks handler call depth tracking for calls to XML_GetBuffer, XML_Parse, XML_ParseBuffer, XML_ParserFree, or XML_ParserReset from within handlers in cases of a policy violation. Thus, a use-after-free can occur,", "cve_priority": "medium", "cve_public_date": "2026-06-04 06:16:00 UTC" }, { "cve": "CVE-2026-56412", "url": "https://ubuntu.com/security/CVE-2026-56412", "cve_description": "libexpat before 2.8.2 does not consider XML_TOK_DATA_CHARS in doCdataSection and thus lacks handler call depth tracking for various calls from within handlers in cases of a policy violation. Thus, a use-after-free can occur. NOTE: this issue exists because of an incomplete fix for CVE-2026-50219.", "cve_priority": "medium", "cve_public_date": "2026-06-21 17:16:00 UTC" }, { "cve": "CVE-2026-56404", "url": "https://ubuntu.com/security/CVE-2026-56404", "cve_description": "libexpat before 2.8.2 has an integer overflow in addBinding.", "cve_priority": "medium", "cve_public_date": "2026-06-21 16:16:00 UTC" }, { "cve": "CVE-2026-56405", "url": "https://ubuntu.com/security/CVE-2026-56405", "cve_description": "libexpat before 2.8.2 has an integer overflow in getAttributeId.", "cve_priority": "medium", "cve_public_date": "2026-06-21 16:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-56410", "url": "https://ubuntu.com/security/CVE-2026-56410", "cve_description": "xmlwf in libexpat before 2.8.2 has an integer overflow in resolveSystemId.", "cve_priority": "medium", "cve_public_date": "2026-06-21 16:16:00 UTC" }, { "cve": "CVE-2026-56406", "url": "https://ubuntu.com/security/CVE-2026-56406", "cve_description": "libexpat before 2.8.2 has an integer overflow in XML_ParseBuffer because it lacked a check that was present in XML_Parse.", "cve_priority": "medium", "cve_public_date": "2026-06-21 16:16:00 UTC" }, { "cve": "CVE-2026-56409", "url": "https://ubuntu.com/security/CVE-2026-56409", "cve_description": "xmlwf in libexpat before 2.8.2 has an integer overflow for the output filename when -d outputDir is used.", "cve_priority": "medium", "cve_public_date": "2026-06-21 16:16:00 UTC" }, { "cve": "CVE-2026-56407", "url": "https://ubuntu.com/security/CVE-2026-56407", "cve_description": "libexpat before 2.8.2 has an integer overflow in doProlog that is related to storeEntityValue and entity textLen.", "cve_priority": "medium", "cve_public_date": "2026-06-21 16:16:00 UTC" }, { "cve": "CVE-2026-56411", "url": "https://ubuntu.com/security/CVE-2026-56411", "cve_description": "xmlwf in libexpat before 2.8.2 has an integer overflow in endDoctypeDecl via NOTATION declarations.", "cve_priority": "medium", "cve_public_date": "2026-06-21 17:16:00 UTC" }, { "cve": "CVE-2026-56131", "url": "https://ubuntu.com/security/CVE-2026-56131", "cve_description": "libexpat before 2.8.2 lacks handler call depth tracking for calls to XML_ResumeParser from within handlers in cases of a policy violation. Thus, a use-after-free can occur (similar to the CVE-2026-50219 situation).", "cve_priority": "medium", "cve_public_date": "2026-06-19 06:17:00 UTC" }, { "cve": "CVE-2026-56132", "url": "https://ubuntu.com/security/CVE-2026-56132", "cve_description": "In libexpat before 2.8.2, there is a heap-based buffer overflow in doProlog in xmlparse.c because scaffold backing array reallocation is mishandled when there is data-structure sharing across parsers.", "cve_priority": "medium", "cve_public_date": "2026-06-19 06:17:00 UTC" }, { "cve": "CVE-2026-72522", "url": "https://ubuntu.com/security/CVE-2026-72522", "cve_description": "libexpat before 2.8.3 has an out-of-bounds read and resultant infinite loop because low surrogates are treated the same as high surrogates during Unicode processing in the *_toUtf16 functions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 04:16:00 UTC" }, { "cve": "CVE-2026-66046", "url": "https://ubuntu.com/security/CVE-2026-66046", "cve_description": "Expat through 2.8.3 contains a denial of service vulnerability caused by quadratic algorithmic complexity in the storeAtts() function in xmlparse.c, where processing N specified attributes with non-normalized values triggers an O(N^2) linear scan of elementType->defaultAtts to determine CDATA status. A remote unauthenticated attacker can supply a single well-formed XML document of a few megabytes to an application parsing untrusted XML to cause excessive CPU consumption, resulting in denial of service without requiring authentication, external entity resolution, or non-default parser options.", "cve_priority": "medium", "cve_public_date": "2026-08-18 15:16:00 UTC" }, { "cve": "CVE-2026-76641", "url": "https://ubuntu.com/security/CVE-2026-76641", "cve_description": "Expat through 2.8.3 contains an out-of-bounds read vulnerability that allows attackers to trigger memory corruption by processing XML with external entity parsers created via XML_ExternalEntityParserCreate. A struct size mismatch between ELEMENT_TYPE members causes storeAtts to read the attIndex member past allocated memory boundaries, resulting in failure to normalize whitespace in non-CDATA attributes or a wild pointer dereference causing a segfault. This vulnerability was introduced by the fix for CVE-2026-66046.", "cve_priority": "medium", "cve_public_date": "2026-08-20 18:16:00 UTC" }, { "cve": "CVE-2026-76957", "url": "https://ubuntu.com/security/CVE-2026-76957", "cve_description": "libexpat before 2.8.4 lacks handler call depth tracking with custom encoding callbacks. Thus, a use-after-free can occur. NOTE: this is similar to CVE-2026-50219, CVE-2026-56131 and CVE-2026-56412.", "cve_priority": "medium", "cve_public_date": "2026-08-20 05:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: integer overflow", " - debian/patches/CVE-2026-56410-1.patch: xmlwf: protect resolveSystemId from", " integer overflow in expat/xmlwf/xmlfile.c.", " - debian/patches/CVE-2026-56410-2.patch: xmlwf: guard each operator in", " resolveSystemId length sum in expat/xmlwf/xmlfile.c.", " - CVE-2026-56410", " * SECURITY UPDATE: integer overflow", " - debian/patches/CVE-2026-56406.patch: lib: Copy overflow check from", " `XML_Parse` to `XML_ParseBuffer` in expat/lib/xmlparse.c.", " - CVE-2026-56406", " * SECURITY UPDATE: integer overflow", " - debian/patches/CVE-2026-56409.patch: xmlwf: protect output path join from", " integer overflow in expat/xmlwf/xmlwf.c.", " - CVE-2026-56409", " * SECURITY UPDATE: integer overflow", " - debian/patches/CVE-2026-56407.patch: cap entity textLen against signed", " integer overflow in expat/lib/xmlparse.c.", " - CVE-2026-56407", " * SECURITY UPDATE: integer overflow", " - debian/patches/CVE-2026-56411.patch: xmlwf: protect notation list", " allocation from integer overflow in expat/xmlwf/xmlwf.c.", " - CVE-2026-56411", " * SECURITY UPDATE: use after free", " - debian/patches/CVE-2026-56131.patch: lib: protect XML_ResumeParser from", " being called from a handler in expat/lib/xmlparse.c,", " expat/tests/handlers.c, expat/tests/handlers.h, expat/tests/misc_tests.c.", " - CVE-2026-56131", " * SECURITY UPDATE: heap-based buffer overflow", " - debian/patches/CVE-2026-56132-pre1.patch: lib: swap '(size_t)(-1)' for C99", " equivalent, 'SIZE_MAX' in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-56132-pre2.patch: lib: use a `size_t` for group", " sizes in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-56132-1.patch: lib: Remove reuse of `m_groupSize`", " to count `m_scaffIndex` allocation in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-56132-2.patch: lib: doProlog: Fix out-of-bound", " scaffolding index store in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-56132-3.patch: tests: Add a test case for", " scaffolding array limits in shared DTDs in expat/tests/basic_tests.c.", " - debian/patches/CVE-2026-56132-4.patch: lib: Remove unnecessary", " `scaffIndex` expansion in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-56132-5.patch: lib: Remove indented scoping of", " `new_connector` local in expat/lib/xmlparse.c.", " - CVE-2026-56132", " * SECURITY UPDATE: out-of-bounds read", " - debian/patches/CVE-2026-72522-1.patch: lib: Improve in-code comment for", " functions *toUtf16 in expat/lib/xmltok.c.", " - debian/patches/CVE-2026-72522-2.patch: lib: Stop functions *_toUtf16 from", " mis-classifying low surrogates as high surrogates in expat/lib/xmltok.c.", " - debian/patches/CVE-2026-72522-3.patch: tests/misc_tests.c: Cover Unicode", " surrogate mix-up in expat/tests/misc_tests.c.", " - debian/patches/CVE-2026-72522-4.patch: lib: Make an exit condition in", " `storeAttributeValue` more defensive in expat/lib/xmlparse.c.", " - CVE-2026-72522", " * SECURITY UPDATE: denial of service (algorithmic complexity of storeAtts())", " - debian/patches/CVE-2026-66046.patch: lib: Rename hash table", " `defaultAttsNames` to `defaultAttForName` in expat/lib/xmlparse.c.", " - CVE-2026-66046", " * SECURITY UPDATE: out-of-bounds read", " - debian/patches/CVE-2026-76641.patch: lib: Fix out-of-bounds read from hash", " table entries created by dtdCopy in expat/lib/xmlparse.c,", " expat/tests/basic_tests.c.", " - CVE-2026-76641", " * SECURITY UPDATE: use after free", " - debian/patches/CVE-2026-76957-1.patch: Protect custom encoding callbacks", " from parser reentry in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-76957-2.patch: Test custom encoding callback", " reentry protection in expat/tests/misc_tests.c.", " - CVE-2026-76957", "" ], "package": "expat", "version": "2.6.1-2ubuntu0.6", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Isabel Garcia Contreras ", "date": "Mon, 21 Sep 2026 16:05:43 -0400" }, { "cves": [ { "cve": "CVE-2025-59375", "url": "https://ubuntu.com/security/CVE-2025-59375", "cve_description": "libexpat in Expat before 2.7.2 allows attackers to trigger large dynamic memory allocations via a small document that is submitted for parsing.", "cve_priority": "medium", "cve_public_date": "2025-09-15 03:15:00 UTC" }, { "cve": "CVE-2026-32776", "url": "https://ubuntu.com/security/CVE-2026-32776", "cve_description": "libexpat before 2.7.5 allows a NULL pointer dereference with empty external parameter entity content.", "cve_priority": "medium", "cve_public_date": "2026-03-16 14:19:00 UTC" }, { "cve": "CVE-2026-32777", "url": "https://ubuntu.com/security/CVE-2026-32777", "cve_description": "libexpat before 2.7.5 allows an infinite loop while parsing DTD content.", "cve_priority": "medium", "cve_public_date": "2026-03-16 14:19:00 UTC" }, { "cve": "CVE-2026-32778", "url": "https://ubuntu.com/security/CVE-2026-32778", "cve_description": "libexpat before 2.7.5 allows a NULL pointer dereference in the function setContext on retry after an earlier ouf-of-memory condition.", "cve_priority": "medium", "cve_public_date": "2026-03-16 14:19:00 UTC" }, { "cve": "CVE-2026-45186", "url": "https://ubuntu.com/security/CVE-2026-45186", "cve_description": "In libexpat before 2.8.1, the computational complexity of attribute name collision checks allows a denial of service via moderately sized crafted XML input.", "cve_priority": "medium", "cve_public_date": "2026-05-10 07:16:00 UTC" }, { "cve": "CVE-2026-41080", "url": "https://ubuntu.com/security/CVE-2026-41080", "cve_description": "libexpat before 2.8.0 uses insufficient entropy, and thus hash flooding can occur via a crafted XML document.", "cve_priority": "medium", "cve_public_date": "2026-04-16 17:16:00 UTC" }, { "cve": "CVE-2026-56408", "url": "https://ubuntu.com/security/CVE-2026-56408", "cve_description": "libexpat before 2.8.2 has an integer overflow in copyString.", "cve_priority": "medium", "cve_public_date": "2026-06-21 16:16:00 UTC" }, { "cve": "CVE-2026-56403", "url": "https://ubuntu.com/security/CVE-2026-56403", "cve_description": "libexpat before 2.8.2 has an integer overflow in storeAtts.", "cve_priority": "medium", "cve_public_date": "2026-06-21 16:16:00 UTC" }, { "cve": "CVE-2026-50219", "url": "https://ubuntu.com/security/CVE-2026-50219", "cve_description": "libexpat before 2.8.2 lacks handler call depth tracking for calls to XML_GetBuffer, XML_Parse, XML_ParseBuffer, XML_ParserFree, or XML_ParserReset from within handlers in cases of a policy violation. Thus, a use-after-free can occur,", "cve_priority": "medium", "cve_public_date": "2026-06-04 06:16:00 UTC" }, { "cve": "CVE-2026-56412", "url": "https://ubuntu.com/security/CVE-2026-56412", "cve_description": "libexpat before 2.8.2 does not consider XML_TOK_DATA_CHARS in doCdataSection and thus lacks handler call depth tracking for various calls from within handlers in cases of a policy violation. Thus, a use-after-free can occur. NOTE: this issue exists because of an incomplete fix for CVE-2026-50219.", "cve_priority": "medium", "cve_public_date": "2026-06-21 17:16:00 UTC" }, { "cve": "CVE-2026-56404", "url": "https://ubuntu.com/security/CVE-2026-56404", "cve_description": "libexpat before 2.8.2 has an integer overflow in addBinding.", "cve_priority": "medium", "cve_public_date": "2026-06-21 16:16:00 UTC" }, { "cve": "CVE-2026-56405", "url": "https://ubuntu.com/security/CVE-2026-56405", "cve_description": "libexpat before 2.8.2 has an integer overflow in getAttributeId.", "cve_priority": "medium", "cve_public_date": "2026-06-21 16:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: large dynamic memory allocations via a small document", " - debian/patches/CVE-2025-59375-1.patch: lib: Make function dtdCreate use", " macro MALLOC in expat/lib/xmlparse.c.", " - debian/patches/CVE-2025-59375-2.patch: lib: Make string pools use macros", " MALLOC, FREE, REALLOC in expat/lib/xmlparse.c.", " - debian/patches/CVE-2025-59375-3.patch: lib: Make function hash tables use", " macros MALLOC and FREE in expat/lib/xmlparse.c.", " - debian/patches/CVE-2025-59375-4.patch: lib: Make function copyString use", " macro MALLOC in expat/lib/xmlparse.c.", " - debian/patches/CVE-2025-59375-5.patch: lib: Make function dtdReset use", " macro FREE in expat/lib/xmlparse.c.", " - debian/patches/CVE-2025-59375-6.patch: lib: Make function dtdDestroy use", " macro FREE in expat/lib/xmlparse.c.", " - debian/patches/CVE-2025-59375-7.patch: lib: Make function dtdCopy use", " macro MALLOC in expat/lib/xmlparse.c.", " - debian/patches/CVE-2025-59375-8.patch: lib: Implement tracking of dynamic", " memory allocations in .github/workflows/data/exported-symbols.txt,", " expat/lib/expat.h, expat/lib/internal.h, expat/lib/libexpat.def.cmake,", " expat/lib/xmlparse.c, expat/tests/basic_tests.c,", " expat/tests/nsalloc_tests.c, expat/xmlwf/xmlwf.c,", " expat/xmlwf/xmlwf_helpgen.py.", " - debian/patches/CVE-2025-59375-9.patch: lib: Make XML_MemFree and", " XML_FreeContentModel match their siblings in expat/lib/xmlparse.c.", " - debian/patches/CVE-2025-59375-10.patch: lib: Exclude XML_Mem* functions", " from allocation tracking in expat/lib/xmlparse.c.", " - debian/patches/CVE-2025-59375-11.patch: lib: Exclude the main input buffer", " from allocation tracking in expat/lib/xmlparse.c.", " - debian/patches/CVE-2025-59375-12.patch: lib: Exclude the content model", " from allocation tracking in expat/lib/xmlparse.c.", " - debian/patches/CVE-2025-59375-13.patch: tests: Cover allocation tracking", " and limiting with tests in expat/lib/internal.h, expat/lib/xmlparse.c,", " expat/tests/alloc_tests.c.", " - debian/patches/CVE-2025-59375-14.patch: xmlwf: Wire allocation tracker", " config to existing arguments -a and -b in expat/doc/xmlwf.xml,", " expat/xmlwf/xmlwf.c, expat/xmlwf/xmlwf_helpgen.py.", " - debian/patches/CVE-2025-59375-15.patch: fuzz: Be robust towards NULL", " return from XML_ExternalEntityParserCreate in", " expat/fuzz/xml_parse_fuzzer.c, expat/fuzz/xml_parsebuffer_fuzzer.c.", " - debian/patches/CVE-2025-59375-16.patch: lib: Document and regression-proof", " absence of integer overflow from expat_realloc in expat/lib/xmlparse.c.", " - debian/patches/CVE-2025-59375-17.patch: lib: Fix alignment of internal", " allocations for some non-amd64 architectures in expat/lib/internal.h,", " expat/lib/xmlparse.c, expat/tests/alloc_tests.c.", " - debian/patches/CVE-2025-59375-18.patch: tests: Fix test guard for test", " related to allocation tracking in expat/tests/alloc_tests.c.", " - debian/patches/CVE-2025-59375-19.patch: tests: Add new test", " test_alloc_tracker_pointer_alignment in expat/tests/alloc_tests.c.", " - debian/patches/CVE-2025-59375-20.patch: lib: Fix detection of asynchronous", " tags in entities in expat/lib/xmlparse.c.", " - debian/patches/CVE-2025-59375-21.patch: tests: Cover", " XML_ERROR_ASYNC_ENTITY cases in expat/tests/misc_tests.c.", " - debian/patches/CVE-2025-59375-22.patch: tests: Add line/column checks to", " async entity tests in expat/tests/misc_tests.c.", " - CVE-2025-59375", " * SECURITY UPDATE: NULL function-pointer dereference", " - debian/patches/CVE-2026-32776.patch: Fix NULL function-pointer dereference", " for empty external parameter entities in expat/lib/xmlparse.c,", " expat/tests/basic_tests.c.", " - CVE-2026-32776", " * SECURITY UPDATE: infinite loop while parsing DTD content", " - debian/patches/CVE-2026-32777-1.patch: lib: Reject XML_TOK_INSTANCE_START", " infinite loop in entityValueProcessor in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-32777-2.patch: misc_tests.c: Cover", " XML_TOK_INSTANCE_START infinite loop case in expat/tests/misc_tests.c.", " - CVE-2026-32777", " * SECURITY UPDATE: NULL pointer dereference", " - debian/patches/CVE-2026-32778-1.patch: copy prefix name to pool before", " lookup in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-32778-2.patch: test that we do not end up with a", " zombie PREFIX in the pool in expat/tests/nsalloc_tests.c.", " - CVE-2026-32778", " * SECURITY UPDATE: denial of service via moderately sized crafted XML input", " - debian/patches/CVE-2026-45186-1.patch: Make", " \"counting_start_element_handler\" count default attrs in", " expat/tests/basic_tests.c, expat/tests/handlers.c, expat/tests/handlers.h.", " - debian/patches/CVE-2026-45186-2.patch: test(attlist): Cover duplicate", " attribute names in expat/tests/basic_tests.c.", " - debian/patches/CVE-2026-45186-3-pre.patch: tests: Migrate test_attributes", " off of g_parser in expat/tests/basic_tests.c.", " - debian/patches/CVE-2026-45186-3.patch: tests: Define .attributes the first", " time around in expat/tests/basic_tests.c.", " - debian/patches/CVE-2026-45186-4.patch: tests: Make", " counting_start_element_handler enforce complete attribute lists in", " expat/tests/handlers.c.", " - debian/patches/CVE-2026-45186-5.patch: lib: Extract a constant for", " upcoming reuse in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-45186-6.patch: lib: Introduce", " ELEMENT_TYPE.defaultAttsNames in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-45186-7.patch: lib: Leverage", " ELEMENT_TYPE.defaultAttsNames for attribute collision detection in", " expat/lib/xmlparse.c.", " - CVE-2026-45186", " * SECURITY UPDATE: hash flooding caused by insufficient entropy", " - debian/patches/CVE-2026-41080-1-pre.patch: lib/xmlparse.c: Address clang-", " tidy warning misc-no-recursion in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-41080-1.patch: lib: Inline function", " `get_hash_secret_salt` in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-41080-2.patch: lib: Drop unused parameter from", " function `generate_hash_secret_salt` in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-41080-3.patch: lib: Migrate hash salt storage to", " larger `struct sipkey` in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-41080-4.patch: lib: Drop unneeded `void *` casts", " in function `generate_hash_secret_salt` in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-41080-5-pre.patch: WASI: remove getpid in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-41080-5.patch: lib: Extract 16 bytes of entropy", " (instead of 4 to 8) for hash flooding protection in expat/lib/internal.h,", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-41080-6.patch: lib: Introduce internal flag", " `m_hash_secret_salt_set` in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-41080-7.patch: lib: Introduce API function", " `XML_SetHashSalt16Bytes` in expat/lib/expat.h, expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-41080-8.patch: lib: Include `XML_SetHashSalt*`", " with entropy debugging in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-41080-9.patch: tests: Add basic coverage to", " `XML_SetHashSalt16Bytes` in expat/tests/basic_tests.c.", " - debian/patches/CVE-2026-41080-10.patch: doc: Document `XML_SetHashSalt` as", " being deprecated in expat/lib/expat.h, expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-41080-11.patch: cmake|windows: add missing export", " for new XML_SetHashSalt16Bytes in expat/lib/libexpat.def.cmake.", " - CVE-2026-41080", " * SECURITY UPDATE: integer overflow", " - debian/patches/CVE-2026-56408.patch: lib: Waterproof `copyString` from", " integer overflow in expat/lib/xmlparse.c.", " - CVE-2026-56408", " * SECURITY UPDATE: integer overflow", " - debian/patches/CVE-2026-56403-pre1.patch: Replace the empty for-loops with", " while loops in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-56403-1.patch: lib: Protect function `storeAtts`", " from signed integer overflow in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-56403-2.patch: xmlwf: Protect function `xcsdup`", " from signed integer overflow in expat/xmlwf/xmlwf.c.", " - CVE-2026-56403", " * SECURITY UPDATE: use after free", " - debian/patches/CVE-2026-50219-1.patch: lib: Introduce handler call depth", " tracking in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-2.patch: lib: Prepare", " `m_notStandaloneHandler` calls for upcoming wrapping in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-3.patch: lib: Prepare", " `m_externalEntityRefHandler` calls for upcoming wrapping in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-4.patch: lib: Prepare", " `m_unknownEncodingHandler` calls for upcoming wrapping in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-5.patch: lib: Register", " `m_attlistDeclHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-6.patch: lib: Register", " `m_characterDataHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-7.patch: lib: Register `m_commentHandler`", " with handler call depth tracking in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-8.patch: lib: Register `m_defaultHandler`", " with handler call depth tracking in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-9.patch: lib: Register", " `m_elementDeclHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-10.patch: lib: Register", " `m_endCdataSectionHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-11.patch: lib: Register", " `m_endDoctypeDeclHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-12.patch: lib: Register", " `m_endElementHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-13.patch: lib: Register", " `m_endNamespaceDeclHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-14.patch: lib: Register", " `m_entityDeclHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-15.patch: lib: Register", " `m_externalEntityRefHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-16.patch: lib: Register", " `m_notationDeclHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-17.patch: lib: Register", " `m_notStandaloneHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-18.patch: lib: Register", " `m_processingInstructionHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-19.patch: lib: Register", " `m_skippedEntityHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-20.patch: lib: Register", " `m_startCdataSectionHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-21.patch: lib: Register", " `m_startDoctypeDeclHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-22.patch: lib: Register", " `m_startElementHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-23.patch: lib: Register", " `m_startNamespaceDeclHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-24.patch: lib: Register", " `m_unknownEncodingHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-25.patch: lib: Register", " `m_unparsedEntityDeclHandler` with handler call depth tracking in", " expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-26.patch: lib: Register `m_xmlDeclHandler`", " with handler call depth tracking in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-27.patch: lib: Protect `XML_GetBuffer` from", " being called from a handler in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-28.patch: lib: Protect `XML_Parse` from", " being called from a handler in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-29.patch: lib: Protect `XML_ParseBuffer`", " from being called from a handler in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-30.patch: lib: Protect `XML_ParserFree` from", " being called from a handler in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-31.patch: lib: Protect `XML_ParserReset`", " from being called from a handler in expat/lib/xmlparse.c.", " - debian/patches/CVE-2026-50219-32.patch: tests: Cover calls forbidden from", " handlers in expat/tests/handlers.c, expat/tests/handlers.h,", " expat/tests/misc_tests.c.", " - CVE-2026-50219", " * SECURITY UPDATE: use after free (fix for CVE-2026-50219 was incomplete)", " - debian/patches/CVE-2026-56412.patch: lib: guard XML_TOK_DATA_CHARS handler", " calls in doCdataSection() in expat/lib/xmlparse.c.", " - CVE-2026-56412", " * SECURITY UPDATE: integer overflow", " - debian/patches/CVE-2026-56404.patch: lib: protect function addBinding from", " signed integer overflow in expat/lib/xmlparse.c.", " - CVE-2026-56404", " * SECURITY UPDATE: integer overflow", " - debian/patches/CVE-2026-56405.patch: lib: Protect function getAttributeId", " from signed integer overflow in expat/lib/xmlparse.c.", " - CVE-2026-56405", "" ], "package": "expat", "version": "2.6.1-2ubuntu0.5", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Isabel Garcia Contreras ", "date": "Fri, 11 Sep 2026 10:26:31 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libglib2.0-0t64:riscv64", "from_version": { "source_package_name": "glib2.0", "source_package_version": "2.80.0-6ubuntu3.8", "version": "2.80.0-6ubuntu3.8" }, "to_version": { "source_package_name": "glib2.0", "source_package_version": "2.80.0-6ubuntu3.9", "version": "2.80.0-6ubuntu3.9" }, "cves": [ { "cve": "CVE-2026-58010", "url": "https://ubuntu.com/security/CVE-2026-58010", "cve_description": "A flaw was found in GLib. An off-by-one error can occur in the gvs_tuple_is_normal function in the glib/gvariant-serialiser.c file when doing an alignment padding check because the bounds check uses > instead of >=, causing an out-of-bounds read of only 1 byte. This issue can cause a minor information disclosure of 1 byte and a denial of service when the out-of-bounds read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58011", "url": "https://ubuntu.com/security/CVE-2026-58011", "cve_description": "A flaw was found in GLib. An out-of-bounds read of only 2 bytes can occur in the g_date_time_get_ymd function in the glib/gdatetime.c file when an invalid GDateTime object produced by the g_date_time_add_full function is processed. This flaw can corrupt the date output and potentially cause logic errors that may lead to a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58012", "url": "https://ubuntu.com/security/CVE-2026-58012", "cve_description": "A flaw was found in GLib. A buffer over-read can occur in the g_regex_replace function when used with the `G_REGEX_RAW` compile flag and case-change replacement escapes because the string_append function processes matched substrings using UTF-8 functions that assume valid UTF-8 input, even when the string is treated as raw bytes. This vulnerability can cause a minor information disclosure of 1-5 bytes and a denial of service when the buffer over-read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58013", "url": "https://ubuntu.com/security/CVE-2026-58013", "cve_description": "A flaw was found in GLib. A buffer over-read can occur in g_io_channel_read_line_backend() in the giochannel.c file when a custom line terminator with a length greater than one is set, causing memcmp to read past the GString buffer. This vulnerability can cause a minor information disclosure of 7 bytes or a denial of service when the buffer over-read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58014", "url": "https://ubuntu.com/security/CVE-2026-58014", "cve_description": "A flaw was found in GLib. An off-by-one error can occur in the g_key_file_get_locale_string_list function in the gkeyfile.c file when loading a key file with an empty value. This flaw can cause an out-of-bounds access of 1 byte or a denial of service when the out-of-bounds access crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58015", "url": "https://ubuntu.com/security/CVE-2026-58015", "cve_description": "A flaw was found in GLib. The D-Bus client-side implementation of the DBUS_COOKIE_SHA1 SASL authentication mechanism does not validate the cookie_context parameter received from the server. A malicious D-Bus server can supply a cookie_context containing path traversal sequences, causing the client to read an arbitrary file and exfiltrate sensitive data by verifying guessed file contents against a generated hash.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58016", "url": "https://ubuntu.com/security/CVE-2026-58016", "cve_description": "A flaw was found in GLib. A state confusion issue exists in g_dbus_node_info_new_for_xml() in the gio/gdbusintrospection.c file when processing malformed D-Bus introspection XML, specifically with a `node` element nested within other elements like `method`, `signal`, `property` or `arg`. This issue can cause an unsigned integer overflow and lead to an out-of-bounds read, resulting in a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-15588", "url": "https://ubuntu.com/security/CVE-2026-15588", "cve_description": "A denial-of-service and resource exhaustion vulnerability exists within the `GDBus` component of GLib. The `gdbusauth` authentication mechanism fails to enforce proper length limitations on data lines read from a client. An unauthenticated local or remote attacker can exploit this lack of input validation by sending excessively long streams of data, causing the application to consume massive amounts of system memory and CPU, potentially leading to a crash or system hang.", "cve_priority": "medium", "cve_public_date": "2026-07-20 12:17:00 UTC" }, { "cve": "CVE-2026-16118", "url": "https://ubuntu.com/security/CVE-2026-16118", "cve_description": "A flaw was found in xdgmime. A heap-based buffer overflow can be triggered in _xdg_mime_magic_parse_magic_line() in the xdgmimemagic.c file on little-endian systems when an attacker-controlled MIME magic file in a user-writable XDG data location (e.g., in the $XDG_DATA_HOME/mime/magic path) is parsed by an application performing MIME type detection (e.g., via g_content_type_guess()). When performing byte-swap, incorrect pointer arithmetic on the write side causes an out-of-bounds write of 2 bytes, resulting in an application crash or memory corruption.", "cve_priority": "medium", "cve_public_date": "2026-07-17 20:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-58010", "url": "https://ubuntu.com/security/CVE-2026-58010", "cve_description": "A flaw was found in GLib. An off-by-one error can occur in the gvs_tuple_is_normal function in the glib/gvariant-serialiser.c file when doing an alignment padding check because the bounds check uses > instead of >=, causing an out-of-bounds read of only 1 byte. This issue can cause a minor information disclosure of 1 byte and a denial of service when the out-of-bounds read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58011", "url": "https://ubuntu.com/security/CVE-2026-58011", "cve_description": "A flaw was found in GLib. An out-of-bounds read of only 2 bytes can occur in the g_date_time_get_ymd function in the glib/gdatetime.c file when an invalid GDateTime object produced by the g_date_time_add_full function is processed. This flaw can corrupt the date output and potentially cause logic errors that may lead to a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58012", "url": "https://ubuntu.com/security/CVE-2026-58012", "cve_description": "A flaw was found in GLib. A buffer over-read can occur in the g_regex_replace function when used with the `G_REGEX_RAW` compile flag and case-change replacement escapes because the string_append function processes matched substrings using UTF-8 functions that assume valid UTF-8 input, even when the string is treated as raw bytes. This vulnerability can cause a minor information disclosure of 1-5 bytes and a denial of service when the buffer over-read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58013", "url": "https://ubuntu.com/security/CVE-2026-58013", "cve_description": "A flaw was found in GLib. A buffer over-read can occur in g_io_channel_read_line_backend() in the giochannel.c file when a custom line terminator with a length greater than one is set, causing memcmp to read past the GString buffer. This vulnerability can cause a minor information disclosure of 7 bytes or a denial of service when the buffer over-read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58014", "url": "https://ubuntu.com/security/CVE-2026-58014", "cve_description": "A flaw was found in GLib. An off-by-one error can occur in the g_key_file_get_locale_string_list function in the gkeyfile.c file when loading a key file with an empty value. This flaw can cause an out-of-bounds access of 1 byte or a denial of service when the out-of-bounds access crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58015", "url": "https://ubuntu.com/security/CVE-2026-58015", "cve_description": "A flaw was found in GLib. The D-Bus client-side implementation of the DBUS_COOKIE_SHA1 SASL authentication mechanism does not validate the cookie_context parameter received from the server. A malicious D-Bus server can supply a cookie_context containing path traversal sequences, causing the client to read an arbitrary file and exfiltrate sensitive data by verifying guessed file contents against a generated hash.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58016", "url": "https://ubuntu.com/security/CVE-2026-58016", "cve_description": "A flaw was found in GLib. A state confusion issue exists in g_dbus_node_info_new_for_xml() in the gio/gdbusintrospection.c file when processing malformed D-Bus introspection XML, specifically with a `node` element nested within other elements like `method`, `signal`, `property` or `arg`. This issue can cause an unsigned integer overflow and lead to an out-of-bounds read, resulting in a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-15588", "url": "https://ubuntu.com/security/CVE-2026-15588", "cve_description": "A denial-of-service and resource exhaustion vulnerability exists within the `GDBus` component of GLib. The `gdbusauth` authentication mechanism fails to enforce proper length limitations on data lines read from a client. An unauthenticated local or remote attacker can exploit this lack of input validation by sending excessively long streams of data, causing the application to consume massive amounts of system memory and CPU, potentially leading to a crash or system hang.", "cve_priority": "medium", "cve_public_date": "2026-07-20 12:17:00 UTC" }, { "cve": "CVE-2026-16118", "url": "https://ubuntu.com/security/CVE-2026-16118", "cve_description": "A flaw was found in xdgmime. A heap-based buffer overflow can be triggered in _xdg_mime_magic_parse_magic_line() in the xdgmimemagic.c file on little-endian systems when an attacker-controlled MIME magic file in a user-writable XDG data location (e.g., in the $XDG_DATA_HOME/mime/magic path) is parsed by an application performing MIME type detection (e.g., via g_content_type_guess()). When performing byte-swap, incorrect pointer arithmetic on the write side causes an out-of-bounds write of 2 bytes, resulting in an application crash or memory corruption.", "cve_priority": "medium", "cve_public_date": "2026-07-17 20:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: off-by-one OOB read in GVariant serialiser", " - debian/patches/CVE-2026-58010.patch: fix bounds check to use >= instead", " of > in gvs_tuple_is_normal() in glib/gvariant-serialiser.c.", " - CVE-2026-58010", " * SECURITY UPDATE: OOB read in GDateTime", " - debian/patches/CVE-2026-58011.patch: add missing range validation to", " g_date_time_add_full() in glib/gdatetime.c.", " - CVE-2026-58011", " * SECURITY UPDATE: buffer over-read in g_regex_replace", " - debian/patches/CVE-2026-58012.patch: fix case-change substitution", " handling with G_REGEX_RAW in glib/gregex.c.", " - CVE-2026-58012", " * SECURITY UPDATE: buffer over-read in GIOChannel", " - debian/patches/CVE-2026-58013.patch: add length check before memcmp", " in g_io_channel_read_line_backend() in glib/giochannel.c.", " - CVE-2026-58013", " * SECURITY UPDATE: off-by-one heap under-read in GKeyFile", " - debian/patches/CVE-2026-58014.patch: add len > 0 check before", " accessing value[len-1] in g_key_file_get_locale_string_list() in", " glib/gkeyfile.c.", " - CVE-2026-58014", " * SECURITY UPDATE: path traversal in DBUS_COOKIE_SHA1 auth", " - debian/patches/CVE-2026-58015.patch: validate cookie_context parameter", " to prevent path traversal in gio/gdbusauthmechanismsha1.c.", " - CVE-2026-58015", " * SECURITY UPDATE: state confusion in D-Bus introspection XML parser", " - debian/patches/CVE-2026-58016.patch: fix node element nesting check", " and add assertions in gio/gdbusintrospection.c.", " - CVE-2026-58016", " * SECURITY UPDATE: resource exhaustion in GDBus authentication", " - debian/patches/CVE-2026-15588.patch: limit length of lines read from", " client in gio/gdbusauth.c.", " - CVE-2026-15588", " * SECURITY UPDATE: heap buffer overflow in xdgmime", " - debian/patches/CVE-2026-16118.patch: fix pointer arithmetic in", " byte-swap routine in gio/xdgmime/xdgmimemagic.c.", " - CVE-2026-16118", "" ], "package": "glib2.0", "version": "2.80.0-6ubuntu3.9", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Leonidas Da Silva Barbosa ", "date": "Tue, 08 Sep 2026 14:07:47 -0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "libglib2.0-bin", "from_version": { "source_package_name": "glib2.0", "source_package_version": "2.80.0-6ubuntu3.8", "version": "2.80.0-6ubuntu3.8" }, "to_version": { "source_package_name": "glib2.0", "source_package_version": "2.80.0-6ubuntu3.9", "version": "2.80.0-6ubuntu3.9" }, "cves": [ { "cve": "CVE-2026-58010", "url": "https://ubuntu.com/security/CVE-2026-58010", "cve_description": "A flaw was found in GLib. An off-by-one error can occur in the gvs_tuple_is_normal function in the glib/gvariant-serialiser.c file when doing an alignment padding check because the bounds check uses > instead of >=, causing an out-of-bounds read of only 1 byte. This issue can cause a minor information disclosure of 1 byte and a denial of service when the out-of-bounds read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58011", "url": "https://ubuntu.com/security/CVE-2026-58011", "cve_description": "A flaw was found in GLib. An out-of-bounds read of only 2 bytes can occur in the g_date_time_get_ymd function in the glib/gdatetime.c file when an invalid GDateTime object produced by the g_date_time_add_full function is processed. This flaw can corrupt the date output and potentially cause logic errors that may lead to a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58012", "url": "https://ubuntu.com/security/CVE-2026-58012", "cve_description": "A flaw was found in GLib. A buffer over-read can occur in the g_regex_replace function when used with the `G_REGEX_RAW` compile flag and case-change replacement escapes because the string_append function processes matched substrings using UTF-8 functions that assume valid UTF-8 input, even when the string is treated as raw bytes. This vulnerability can cause a minor information disclosure of 1-5 bytes and a denial of service when the buffer over-read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58013", "url": "https://ubuntu.com/security/CVE-2026-58013", "cve_description": "A flaw was found in GLib. A buffer over-read can occur in g_io_channel_read_line_backend() in the giochannel.c file when a custom line terminator with a length greater than one is set, causing memcmp to read past the GString buffer. This vulnerability can cause a minor information disclosure of 7 bytes or a denial of service when the buffer over-read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58014", "url": "https://ubuntu.com/security/CVE-2026-58014", "cve_description": "A flaw was found in GLib. An off-by-one error can occur in the g_key_file_get_locale_string_list function in the gkeyfile.c file when loading a key file with an empty value. This flaw can cause an out-of-bounds access of 1 byte or a denial of service when the out-of-bounds access crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58015", "url": "https://ubuntu.com/security/CVE-2026-58015", "cve_description": "A flaw was found in GLib. The D-Bus client-side implementation of the DBUS_COOKIE_SHA1 SASL authentication mechanism does not validate the cookie_context parameter received from the server. A malicious D-Bus server can supply a cookie_context containing path traversal sequences, causing the client to read an arbitrary file and exfiltrate sensitive data by verifying guessed file contents against a generated hash.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58016", "url": "https://ubuntu.com/security/CVE-2026-58016", "cve_description": "A flaw was found in GLib. A state confusion issue exists in g_dbus_node_info_new_for_xml() in the gio/gdbusintrospection.c file when processing malformed D-Bus introspection XML, specifically with a `node` element nested within other elements like `method`, `signal`, `property` or `arg`. This issue can cause an unsigned integer overflow and lead to an out-of-bounds read, resulting in a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-15588", "url": "https://ubuntu.com/security/CVE-2026-15588", "cve_description": "A denial-of-service and resource exhaustion vulnerability exists within the `GDBus` component of GLib. The `gdbusauth` authentication mechanism fails to enforce proper length limitations on data lines read from a client. An unauthenticated local or remote attacker can exploit this lack of input validation by sending excessively long streams of data, causing the application to consume massive amounts of system memory and CPU, potentially leading to a crash or system hang.", "cve_priority": "medium", "cve_public_date": "2026-07-20 12:17:00 UTC" }, { "cve": "CVE-2026-16118", "url": "https://ubuntu.com/security/CVE-2026-16118", "cve_description": "A flaw was found in xdgmime. A heap-based buffer overflow can be triggered in _xdg_mime_magic_parse_magic_line() in the xdgmimemagic.c file on little-endian systems when an attacker-controlled MIME magic file in a user-writable XDG data location (e.g., in the $XDG_DATA_HOME/mime/magic path) is parsed by an application performing MIME type detection (e.g., via g_content_type_guess()). When performing byte-swap, incorrect pointer arithmetic on the write side causes an out-of-bounds write of 2 bytes, resulting in an application crash or memory corruption.", "cve_priority": "medium", "cve_public_date": "2026-07-17 20:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-58010", "url": "https://ubuntu.com/security/CVE-2026-58010", "cve_description": "A flaw was found in GLib. An off-by-one error can occur in the gvs_tuple_is_normal function in the glib/gvariant-serialiser.c file when doing an alignment padding check because the bounds check uses > instead of >=, causing an out-of-bounds read of only 1 byte. This issue can cause a minor information disclosure of 1 byte and a denial of service when the out-of-bounds read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58011", "url": "https://ubuntu.com/security/CVE-2026-58011", "cve_description": "A flaw was found in GLib. An out-of-bounds read of only 2 bytes can occur in the g_date_time_get_ymd function in the glib/gdatetime.c file when an invalid GDateTime object produced by the g_date_time_add_full function is processed. This flaw can corrupt the date output and potentially cause logic errors that may lead to a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58012", "url": "https://ubuntu.com/security/CVE-2026-58012", "cve_description": "A flaw was found in GLib. A buffer over-read can occur in the g_regex_replace function when used with the `G_REGEX_RAW` compile flag and case-change replacement escapes because the string_append function processes matched substrings using UTF-8 functions that assume valid UTF-8 input, even when the string is treated as raw bytes. This vulnerability can cause a minor information disclosure of 1-5 bytes and a denial of service when the buffer over-read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58013", "url": "https://ubuntu.com/security/CVE-2026-58013", "cve_description": "A flaw was found in GLib. A buffer over-read can occur in g_io_channel_read_line_backend() in the giochannel.c file when a custom line terminator with a length greater than one is set, causing memcmp to read past the GString buffer. This vulnerability can cause a minor information disclosure of 7 bytes or a denial of service when the buffer over-read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58014", "url": "https://ubuntu.com/security/CVE-2026-58014", "cve_description": "A flaw was found in GLib. An off-by-one error can occur in the g_key_file_get_locale_string_list function in the gkeyfile.c file when loading a key file with an empty value. This flaw can cause an out-of-bounds access of 1 byte or a denial of service when the out-of-bounds access crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58015", "url": "https://ubuntu.com/security/CVE-2026-58015", "cve_description": "A flaw was found in GLib. The D-Bus client-side implementation of the DBUS_COOKIE_SHA1 SASL authentication mechanism does not validate the cookie_context parameter received from the server. A malicious D-Bus server can supply a cookie_context containing path traversal sequences, causing the client to read an arbitrary file and exfiltrate sensitive data by verifying guessed file contents against a generated hash.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58016", "url": "https://ubuntu.com/security/CVE-2026-58016", "cve_description": "A flaw was found in GLib. A state confusion issue exists in g_dbus_node_info_new_for_xml() in the gio/gdbusintrospection.c file when processing malformed D-Bus introspection XML, specifically with a `node` element nested within other elements like `method`, `signal`, `property` or `arg`. This issue can cause an unsigned integer overflow and lead to an out-of-bounds read, resulting in a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-15588", "url": "https://ubuntu.com/security/CVE-2026-15588", "cve_description": "A denial-of-service and resource exhaustion vulnerability exists within the `GDBus` component of GLib. The `gdbusauth` authentication mechanism fails to enforce proper length limitations on data lines read from a client. An unauthenticated local or remote attacker can exploit this lack of input validation by sending excessively long streams of data, causing the application to consume massive amounts of system memory and CPU, potentially leading to a crash or system hang.", "cve_priority": "medium", "cve_public_date": "2026-07-20 12:17:00 UTC" }, { "cve": "CVE-2026-16118", "url": "https://ubuntu.com/security/CVE-2026-16118", "cve_description": "A flaw was found in xdgmime. A heap-based buffer overflow can be triggered in _xdg_mime_magic_parse_magic_line() in the xdgmimemagic.c file on little-endian systems when an attacker-controlled MIME magic file in a user-writable XDG data location (e.g., in the $XDG_DATA_HOME/mime/magic path) is parsed by an application performing MIME type detection (e.g., via g_content_type_guess()). When performing byte-swap, incorrect pointer arithmetic on the write side causes an out-of-bounds write of 2 bytes, resulting in an application crash or memory corruption.", "cve_priority": "medium", "cve_public_date": "2026-07-17 20:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: off-by-one OOB read in GVariant serialiser", " - debian/patches/CVE-2026-58010.patch: fix bounds check to use >= instead", " of > in gvs_tuple_is_normal() in glib/gvariant-serialiser.c.", " - CVE-2026-58010", " * SECURITY UPDATE: OOB read in GDateTime", " - debian/patches/CVE-2026-58011.patch: add missing range validation to", " g_date_time_add_full() in glib/gdatetime.c.", " - CVE-2026-58011", " * SECURITY UPDATE: buffer over-read in g_regex_replace", " - debian/patches/CVE-2026-58012.patch: fix case-change substitution", " handling with G_REGEX_RAW in glib/gregex.c.", " - CVE-2026-58012", " * SECURITY UPDATE: buffer over-read in GIOChannel", " - debian/patches/CVE-2026-58013.patch: add length check before memcmp", " in g_io_channel_read_line_backend() in glib/giochannel.c.", " - CVE-2026-58013", " * SECURITY UPDATE: off-by-one heap under-read in GKeyFile", " - debian/patches/CVE-2026-58014.patch: add len > 0 check before", " accessing value[len-1] in g_key_file_get_locale_string_list() in", " glib/gkeyfile.c.", " - CVE-2026-58014", " * SECURITY UPDATE: path traversal in DBUS_COOKIE_SHA1 auth", " - debian/patches/CVE-2026-58015.patch: validate cookie_context parameter", " to prevent path traversal in gio/gdbusauthmechanismsha1.c.", " - CVE-2026-58015", " * SECURITY UPDATE: state confusion in D-Bus introspection XML parser", " - debian/patches/CVE-2026-58016.patch: fix node element nesting check", " and add assertions in gio/gdbusintrospection.c.", " - CVE-2026-58016", " * SECURITY UPDATE: resource exhaustion in GDBus authentication", " - debian/patches/CVE-2026-15588.patch: limit length of lines read from", " client in gio/gdbusauth.c.", " - CVE-2026-15588", " * SECURITY UPDATE: heap buffer overflow in xdgmime", " - debian/patches/CVE-2026-16118.patch: fix pointer arithmetic in", " byte-swap routine in gio/xdgmime/xdgmimemagic.c.", " - CVE-2026-16118", "" ], "package": "glib2.0", "version": "2.80.0-6ubuntu3.9", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Leonidas Da Silva Barbosa ", "date": "Tue, 08 Sep 2026 14:07:47 -0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "libglib2.0-data", "from_version": { "source_package_name": "glib2.0", "source_package_version": "2.80.0-6ubuntu3.8", "version": "2.80.0-6ubuntu3.8" }, "to_version": { "source_package_name": "glib2.0", "source_package_version": "2.80.0-6ubuntu3.9", "version": "2.80.0-6ubuntu3.9" }, "cves": [ { "cve": "CVE-2026-58010", "url": "https://ubuntu.com/security/CVE-2026-58010", "cve_description": "A flaw was found in GLib. An off-by-one error can occur in the gvs_tuple_is_normal function in the glib/gvariant-serialiser.c file when doing an alignment padding check because the bounds check uses > instead of >=, causing an out-of-bounds read of only 1 byte. This issue can cause a minor information disclosure of 1 byte and a denial of service when the out-of-bounds read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58011", "url": "https://ubuntu.com/security/CVE-2026-58011", "cve_description": "A flaw was found in GLib. An out-of-bounds read of only 2 bytes can occur in the g_date_time_get_ymd function in the glib/gdatetime.c file when an invalid GDateTime object produced by the g_date_time_add_full function is processed. This flaw can corrupt the date output and potentially cause logic errors that may lead to a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58012", "url": "https://ubuntu.com/security/CVE-2026-58012", "cve_description": "A flaw was found in GLib. A buffer over-read can occur in the g_regex_replace function when used with the `G_REGEX_RAW` compile flag and case-change replacement escapes because the string_append function processes matched substrings using UTF-8 functions that assume valid UTF-8 input, even when the string is treated as raw bytes. This vulnerability can cause a minor information disclosure of 1-5 bytes and a denial of service when the buffer over-read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58013", "url": "https://ubuntu.com/security/CVE-2026-58013", "cve_description": "A flaw was found in GLib. A buffer over-read can occur in g_io_channel_read_line_backend() in the giochannel.c file when a custom line terminator with a length greater than one is set, causing memcmp to read past the GString buffer. This vulnerability can cause a minor information disclosure of 7 bytes or a denial of service when the buffer over-read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58014", "url": "https://ubuntu.com/security/CVE-2026-58014", "cve_description": "A flaw was found in GLib. An off-by-one error can occur in the g_key_file_get_locale_string_list function in the gkeyfile.c file when loading a key file with an empty value. This flaw can cause an out-of-bounds access of 1 byte or a denial of service when the out-of-bounds access crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58015", "url": "https://ubuntu.com/security/CVE-2026-58015", "cve_description": "A flaw was found in GLib. The D-Bus client-side implementation of the DBUS_COOKIE_SHA1 SASL authentication mechanism does not validate the cookie_context parameter received from the server. A malicious D-Bus server can supply a cookie_context containing path traversal sequences, causing the client to read an arbitrary file and exfiltrate sensitive data by verifying guessed file contents against a generated hash.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58016", "url": "https://ubuntu.com/security/CVE-2026-58016", "cve_description": "A flaw was found in GLib. A state confusion issue exists in g_dbus_node_info_new_for_xml() in the gio/gdbusintrospection.c file when processing malformed D-Bus introspection XML, specifically with a `node` element nested within other elements like `method`, `signal`, `property` or `arg`. This issue can cause an unsigned integer overflow and lead to an out-of-bounds read, resulting in a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-15588", "url": "https://ubuntu.com/security/CVE-2026-15588", "cve_description": "A denial-of-service and resource exhaustion vulnerability exists within the `GDBus` component of GLib. The `gdbusauth` authentication mechanism fails to enforce proper length limitations on data lines read from a client. An unauthenticated local or remote attacker can exploit this lack of input validation by sending excessively long streams of data, causing the application to consume massive amounts of system memory and CPU, potentially leading to a crash or system hang.", "cve_priority": "medium", "cve_public_date": "2026-07-20 12:17:00 UTC" }, { "cve": "CVE-2026-16118", "url": "https://ubuntu.com/security/CVE-2026-16118", "cve_description": "A flaw was found in xdgmime. A heap-based buffer overflow can be triggered in _xdg_mime_magic_parse_magic_line() in the xdgmimemagic.c file on little-endian systems when an attacker-controlled MIME magic file in a user-writable XDG data location (e.g., in the $XDG_DATA_HOME/mime/magic path) is parsed by an application performing MIME type detection (e.g., via g_content_type_guess()). When performing byte-swap, incorrect pointer arithmetic on the write side causes an out-of-bounds write of 2 bytes, resulting in an application crash or memory corruption.", "cve_priority": "medium", "cve_public_date": "2026-07-17 20:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-58010", "url": "https://ubuntu.com/security/CVE-2026-58010", "cve_description": "A flaw was found in GLib. An off-by-one error can occur in the gvs_tuple_is_normal function in the glib/gvariant-serialiser.c file when doing an alignment padding check because the bounds check uses > instead of >=, causing an out-of-bounds read of only 1 byte. This issue can cause a minor information disclosure of 1 byte and a denial of service when the out-of-bounds read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58011", "url": "https://ubuntu.com/security/CVE-2026-58011", "cve_description": "A flaw was found in GLib. An out-of-bounds read of only 2 bytes can occur in the g_date_time_get_ymd function in the glib/gdatetime.c file when an invalid GDateTime object produced by the g_date_time_add_full function is processed. This flaw can corrupt the date output and potentially cause logic errors that may lead to a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58012", "url": "https://ubuntu.com/security/CVE-2026-58012", "cve_description": "A flaw was found in GLib. A buffer over-read can occur in the g_regex_replace function when used with the `G_REGEX_RAW` compile flag and case-change replacement escapes because the string_append function processes matched substrings using UTF-8 functions that assume valid UTF-8 input, even when the string is treated as raw bytes. This vulnerability can cause a minor information disclosure of 1-5 bytes and a denial of service when the buffer over-read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58013", "url": "https://ubuntu.com/security/CVE-2026-58013", "cve_description": "A flaw was found in GLib. A buffer over-read can occur in g_io_channel_read_line_backend() in the giochannel.c file when a custom line terminator with a length greater than one is set, causing memcmp to read past the GString buffer. This vulnerability can cause a minor information disclosure of 7 bytes or a denial of service when the buffer over-read crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58014", "url": "https://ubuntu.com/security/CVE-2026-58014", "cve_description": "A flaw was found in GLib. An off-by-one error can occur in the g_key_file_get_locale_string_list function in the gkeyfile.c file when loading a key file with an empty value. This flaw can cause an out-of-bounds access of 1 byte or a denial of service when the out-of-bounds access crosses a page boundary.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58015", "url": "https://ubuntu.com/security/CVE-2026-58015", "cve_description": "A flaw was found in GLib. The D-Bus client-side implementation of the DBUS_COOKIE_SHA1 SASL authentication mechanism does not validate the cookie_context parameter received from the server. A malicious D-Bus server can supply a cookie_context containing path traversal sequences, causing the client to read an arbitrary file and exfiltrate sensitive data by verifying guessed file contents against a generated hash.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-58016", "url": "https://ubuntu.com/security/CVE-2026-58016", "cve_description": "A flaw was found in GLib. A state confusion issue exists in g_dbus_node_info_new_for_xml() in the gio/gdbusintrospection.c file when processing malformed D-Bus introspection XML, specifically with a `node` element nested within other elements like `method`, `signal`, `property` or `arg`. This issue can cause an unsigned integer overflow and lead to an out-of-bounds read, resulting in a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-06-30 13:19:00 UTC" }, { "cve": "CVE-2026-15588", "url": "https://ubuntu.com/security/CVE-2026-15588", "cve_description": "A denial-of-service and resource exhaustion vulnerability exists within the `GDBus` component of GLib. The `gdbusauth` authentication mechanism fails to enforce proper length limitations on data lines read from a client. An unauthenticated local or remote attacker can exploit this lack of input validation by sending excessively long streams of data, causing the application to consume massive amounts of system memory and CPU, potentially leading to a crash or system hang.", "cve_priority": "medium", "cve_public_date": "2026-07-20 12:17:00 UTC" }, { "cve": "CVE-2026-16118", "url": "https://ubuntu.com/security/CVE-2026-16118", "cve_description": "A flaw was found in xdgmime. A heap-based buffer overflow can be triggered in _xdg_mime_magic_parse_magic_line() in the xdgmimemagic.c file on little-endian systems when an attacker-controlled MIME magic file in a user-writable XDG data location (e.g., in the $XDG_DATA_HOME/mime/magic path) is parsed by an application performing MIME type detection (e.g., via g_content_type_guess()). When performing byte-swap, incorrect pointer arithmetic on the write side causes an out-of-bounds write of 2 bytes, resulting in an application crash or memory corruption.", "cve_priority": "medium", "cve_public_date": "2026-07-17 20:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: off-by-one OOB read in GVariant serialiser", " - debian/patches/CVE-2026-58010.patch: fix bounds check to use >= instead", " of > in gvs_tuple_is_normal() in glib/gvariant-serialiser.c.", " - CVE-2026-58010", " * SECURITY UPDATE: OOB read in GDateTime", " - debian/patches/CVE-2026-58011.patch: add missing range validation to", " g_date_time_add_full() in glib/gdatetime.c.", " - CVE-2026-58011", " * SECURITY UPDATE: buffer over-read in g_regex_replace", " - debian/patches/CVE-2026-58012.patch: fix case-change substitution", " handling with G_REGEX_RAW in glib/gregex.c.", " - CVE-2026-58012", " * SECURITY UPDATE: buffer over-read in GIOChannel", " - debian/patches/CVE-2026-58013.patch: add length check before memcmp", " in g_io_channel_read_line_backend() in glib/giochannel.c.", " - CVE-2026-58013", " * SECURITY UPDATE: off-by-one heap under-read in GKeyFile", " - debian/patches/CVE-2026-58014.patch: add len > 0 check before", " accessing value[len-1] in g_key_file_get_locale_string_list() in", " glib/gkeyfile.c.", " - CVE-2026-58014", " * SECURITY UPDATE: path traversal in DBUS_COOKIE_SHA1 auth", " - debian/patches/CVE-2026-58015.patch: validate cookie_context parameter", " to prevent path traversal in gio/gdbusauthmechanismsha1.c.", " - CVE-2026-58015", " * SECURITY UPDATE: state confusion in D-Bus introspection XML parser", " - debian/patches/CVE-2026-58016.patch: fix node element nesting check", " and add assertions in gio/gdbusintrospection.c.", " - CVE-2026-58016", " * SECURITY UPDATE: resource exhaustion in GDBus authentication", " - debian/patches/CVE-2026-15588.patch: limit length of lines read from", " client in gio/gdbusauth.c.", " - CVE-2026-15588", " * SECURITY UPDATE: heap buffer overflow in xdgmime", " - debian/patches/CVE-2026-16118.patch: fix pointer arithmetic in", " byte-swap routine in gio/xdgmime/xdgmimemagic.c.", " - CVE-2026-16118", "" ], "package": "glib2.0", "version": "2.80.0-6ubuntu3.9", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Leonidas Da Silva Barbosa ", "date": "Tue, 08 Sep 2026 14:07:47 -0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "libgssapi-krb5-2:riscv64", "from_version": { "source_package_name": "krb5", "source_package_version": "1.20.1-6ubuntu2.8", "version": "1.20.1-6ubuntu2.8" }, "to_version": { "source_package_name": "krb5", "source_package_version": "1.20.1-6ubuntu2.10", "version": "1.20.1-6ubuntu2.10" }, "cves": [], "launchpad_bugs_fixed": [ 2162744 ], "changes": [ { "cves": [], "log": [ "", " * d/t/control: Don't run kinit-pwexpire on 32-bit architectures", " The test verifies correct behavior for dates in the far future", " (~70 years after the time of test), which krb5's date parser", " only accepts on 64 bit arches.", "" ], "package": "krb5", "version": "1.20.1-6ubuntu2.10", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Grayson Wolf ", "date": "Thu, 20 Aug 2026 09:07:25 -0400" }, { "cves": [], "log": [ "", " * d/p/lp2162744-ts-interval.patch: Add ts_interval to accomodate", " for large time intervals (LP: #2162744)", " * d/t/kinit-pwexpire: Add test that long PW expiry dates", " do not overflow and produce wrong messages.", "" ], "package": "krb5", "version": "1.20.1-6ubuntu2.9", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2162744 ], "author": "Grayson Wolf ", "date": "Tue, 11 Aug 2026 17:30:54 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libisns0t64:riscv64", "from_version": { "source_package_name": "open-isns", "source_package_version": "0.101-0.3build3", "version": "0.101-0.3build3" }, "to_version": { "source_package_name": "open-isns", "source_package_version": "0.101-0.3ubuntu0.1", "version": "0.101-0.3ubuntu0.1" }, "cves": [ { "cve": "CVE-2026-55995", "url": "https://ubuntu.com/security/CVE-2026-55995", "cve_description": "A Double Free vulnerability in open-iscsi allows an unauthenticated MITM attacker to cause DoS. This issue affects open-iscsi: from ? through 56718d4e9d1a4f51c30697b5c0534144bb41c9bb.", "cve_priority": "medium", "cve_public_date": "2026-07-29 14:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-55995", "url": "https://ubuntu.com/security/CVE-2026-55995", "cve_description": "A Double Free vulnerability in open-iscsi allows an unauthenticated MITM attacker to cause DoS. This issue affects open-iscsi: from ? through 56718d4e9d1a4f51c30697b5c0534144bb41c9bb.", "cve_priority": "medium", "cve_public_date": "2026-07-29 14:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Fix double-free in malformed attribute error handling.", " - debian/patches/CVE-2026-55995.patch: Fix issue in error path causing", " double-free. in attrs.c.", " - CVE-2026-55995", "" ], "package": "open-isns", "version": "0.101-0.3ubuntu0.1", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Isabel Garcia Contreras ", "date": "Tue, 22 Sep 2026 13:19:29 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libk5crypto3:riscv64", "from_version": { "source_package_name": "krb5", "source_package_version": "1.20.1-6ubuntu2.8", "version": "1.20.1-6ubuntu2.8" }, "to_version": { "source_package_name": "krb5", "source_package_version": "1.20.1-6ubuntu2.10", "version": "1.20.1-6ubuntu2.10" }, "cves": [], "launchpad_bugs_fixed": [ 2162744 ], "changes": [ { "cves": [], "log": [ "", " * d/t/control: Don't run kinit-pwexpire on 32-bit architectures", " The test verifies correct behavior for dates in the far future", " (~70 years after the time of test), which krb5's date parser", " only accepts on 64 bit arches.", "" ], "package": "krb5", "version": "1.20.1-6ubuntu2.10", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Grayson Wolf ", "date": "Thu, 20 Aug 2026 09:07:25 -0400" }, { "cves": [], "log": [ "", " * d/p/lp2162744-ts-interval.patch: Add ts_interval to accomodate", " for large time intervals (LP: #2162744)", " * d/t/kinit-pwexpire: Add test that long PW expiry dates", " do not overflow and produce wrong messages.", "" ], "package": "krb5", "version": "1.20.1-6ubuntu2.9", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2162744 ], "author": "Grayson Wolf ", "date": "Tue, 11 Aug 2026 17:30:54 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libkrb5-3:riscv64", "from_version": { "source_package_name": "krb5", "source_package_version": "1.20.1-6ubuntu2.8", "version": "1.20.1-6ubuntu2.8" }, "to_version": { "source_package_name": "krb5", "source_package_version": "1.20.1-6ubuntu2.10", "version": "1.20.1-6ubuntu2.10" }, "cves": [], "launchpad_bugs_fixed": [ 2162744 ], "changes": [ { "cves": [], "log": [ "", " * d/t/control: Don't run kinit-pwexpire on 32-bit architectures", " The test verifies correct behavior for dates in the far future", " (~70 years after the time of test), which krb5's date parser", " only accepts on 64 bit arches.", "" ], "package": "krb5", "version": "1.20.1-6ubuntu2.10", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Grayson Wolf ", "date": "Thu, 20 Aug 2026 09:07:25 -0400" }, { "cves": [], "log": [ "", " * d/p/lp2162744-ts-interval.patch: Add ts_interval to accomodate", " for large time intervals (LP: #2162744)", " * d/t/kinit-pwexpire: Add test that long PW expiry dates", " do not overflow and produce wrong messages.", "" ], "package": "krb5", "version": "1.20.1-6ubuntu2.9", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2162744 ], "author": "Grayson Wolf ", "date": "Tue, 11 Aug 2026 17:30:54 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libkrb5support0:riscv64", "from_version": { "source_package_name": "krb5", "source_package_version": "1.20.1-6ubuntu2.8", "version": "1.20.1-6ubuntu2.8" }, "to_version": { "source_package_name": "krb5", "source_package_version": "1.20.1-6ubuntu2.10", "version": "1.20.1-6ubuntu2.10" }, "cves": [], "launchpad_bugs_fixed": [ 2162744 ], "changes": [ { "cves": [], "log": [ "", " * d/t/control: Don't run kinit-pwexpire on 32-bit architectures", " The test verifies correct behavior for dates in the far future", " (~70 years after the time of test), which krb5's date parser", " only accepts on 64 bit arches.", "" ], "package": "krb5", "version": "1.20.1-6ubuntu2.10", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Grayson Wolf ", "date": "Thu, 20 Aug 2026 09:07:25 -0400" }, { "cves": [], "log": [ "", " * d/p/lp2162744-ts-interval.patch: Add ts_interval to accomodate", " for large time intervals (LP: #2162744)", " * d/t/kinit-pwexpire: Add test that long PW expiry dates", " do not overflow and produce wrong messages.", "" ], "package": "krb5", "version": "1.20.1-6ubuntu2.9", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2162744 ], "author": "Grayson Wolf ", "date": "Tue, 11 Aug 2026 17:30:54 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libnetplan1:riscv64", "from_version": { "source_package_name": "netplan.io", "source_package_version": "1.1.2-8ubuntu1~24.04.2", "version": "1.1.2-8ubuntu1~24.04.2" }, "to_version": { "source_package_name": "netplan.io", "source_package_version": "1.1.2-8ubuntu1~24.04.3", "version": "1.1.2-8ubuntu1~24.04.3" }, "cves": [], "launchpad_bugs_fixed": [ 2104373 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2104373-return-exit-code-1-on-error.patch: return exit code 1 when", " netplan exits on error (LP: #2104373)", "" ], "package": "netplan.io", "version": "1.1.2-8ubuntu1~24.04.3", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2104373 ], "author": "Guilherme Puida Moreira ", "date": "Mon, 31 Aug 2026 09:19:49 -0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpcap0.8t64:riscv64", "from_version": { "source_package_name": "libpcap", "source_package_version": "1.10.4-4.1ubuntu3", "version": "1.10.4-4.1ubuntu3" }, "to_version": { "source_package_name": "libpcap", "source_package_version": "1.10.4-4.1ubuntu3.1", "version": "1.10.4-4.1ubuntu3.1" }, "cves": [ { "cve": "CVE-2026-0799", "url": "https://ubuntu.com/security/CVE-2026-0799", "cve_description": "In BPF instructions that load/store a value from/to a scratch memory register the register index is an unsigned 32-bit integer and must not exceed 15, but libpcap BPF interpreter does not validate the value. In particular uncommon use cases a crafted filter program can cause the interpreter to try reading and writing the OS process memory in the 16GiB starting at the current stack frame on 64-bit architectures and in the entire address space on 32-bit architectures.", "cve_priority": "medium", "cve_public_date": "2026-09-05 19:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-0799", "url": "https://ubuntu.com/security/CVE-2026-0799", "cve_description": "In BPF instructions that load/store a value from/to a scratch memory register the register index is an unsigned 32-bit integer and must not exceed 15, but libpcap BPF interpreter does not validate the value. In particular uncommon use cases a crafted filter program can cause the interpreter to try reading and writing the OS process memory in the 16GiB starting at the current stack frame on 64-bit architectures and in the entire address space on 32-bit architectures.", "cve_priority": "medium", "cve_public_date": "2026-09-05 19:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer overflow", " - debian/patches/CVE-2026-0799.patch: validate the scratch memory register", " index in bpf_filter() and reject packets with an out-of-range index", " - CVE-2026-0799", "" ], "package": "libpcap", "version": "1.10.4-4.1ubuntu3.1", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Nishit Majithia ", "date": "Fri, 25 Sep 2026 11:44:00 +0530" } ], "notes": null, "is_version_downgrade": false }, { "name": "libperl5.38t64:riscv64", "from_version": { "source_package_name": "perl", "source_package_version": "5.38.2-3.2ubuntu0.4", "version": "5.38.2-3.2ubuntu0.4" }, "to_version": { "source_package_name": "perl", "source_package_version": "5.38.2-3.2ubuntu0.6", "version": "5.38.2-3.2ubuntu0.6" }, "cves": [ { "cve": "CVE-2026-15534", "url": "https://ubuntu.com/security/CVE-2026-15534", "cve_description": "Perl versions through 5.45.1 have out-of-bounds heap reads and writes during regular expression matching via an undersized superlinear cache in S_regmatch. The regex engine's superlinear cache holds one bit per subject position for each participating WHILEM node, so the bit count is the subject length plus one times the number of nodes. Nothing checks that product for positive overflow of the signed 32-bit count: a 286331153 byte subject matched against a pattern with 15 participating nodes stores the count as 14, leaving a two byte cache. The cache is then indexed from the real match position and node number, so reads go past the end of the allocation, and on failure CACHEsayNO sets a bit past it. A caller that matches an attacker controlled subject of this size against a pattern of this shape can crash the process or corrupt heap memory.", "cve_priority": "medium", "cve_public_date": "2026-08-09 18:16:00 UTC" }, { "cve": "CVE-2026-19487", "url": "https://ubuntu.com/security/CVE-2026-19487", "cve_description": "Perl versions from 5.9.4 before 5.41.9 produce incorrect regular expression match results when a stale failure flag ends the Aho-Corasick prescan early in S_find_byclass. The prescan walks the subject for positions where the full pattern could match, and the engine tries it from the leftmost one recorded. A failing transition sets the failed flag, and a later successful transition does not clear it, so the prescan reads the stale flag as a failure and stops before it can record a candidate that starts earlier. It takes a subject where one candidate is recorded and a later character then forces a fallback through a fail link that succeeds. Example: \"ABCDE\" =~ m/ABCF|BCDE|C/; # matches C at offset 2, not BCDE \"ABCDE\" =~ m/ABCF|BCDE|C(G)/; # no match, BCDE missed An alternation like this can miss input it should match, or match it on the wrong branch, so an access or filtering decision made from the result can be wrong.", "cve_priority": "medium", "cve_public_date": "2026-08-13 16:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-15534", "url": "https://ubuntu.com/security/CVE-2026-15534", "cve_description": "Perl versions through 5.45.1 have out-of-bounds heap reads and writes during regular expression matching via an undersized superlinear cache in S_regmatch. The regex engine's superlinear cache holds one bit per subject position for each participating WHILEM node, so the bit count is the subject length plus one times the number of nodes. Nothing checks that product for positive overflow of the signed 32-bit count: a 286331153 byte subject matched against a pattern with 15 participating nodes stores the count as 14, leaving a two byte cache. The cache is then indexed from the real match position and node number, so reads go past the end of the allocation, and on failure CACHEsayNO sets a bit past it. A caller that matches an attacker controlled subject of this size against a pattern of this shape can crash the process or corrupt heap memory.", "cve_priority": "medium", "cve_public_date": "2026-08-09 18:16:00 UTC" }, { "cve": "CVE-2026-19487", "url": "https://ubuntu.com/security/CVE-2026-19487", "cve_description": "Perl versions from 5.9.4 before 5.41.9 produce incorrect regular expression match results when a stale failure flag ends the Aho-Corasick prescan early in S_find_byclass. The prescan walks the subject for positions where the full pattern could match, and the engine tries it from the leftmost one recorded. A failing transition sets the failed flag, and a later successful transition does not clear it, so the prescan reads the stale flag as a failure and stops before it can record a candidate that starts earlier. It takes a subject where one candidate is recorded and a later character then forces a fallback through a fail link that succeeds. Example: \"ABCDE\" =~ m/ABCF|BCDE|C/; # matches C at offset 2, not BCDE \"ABCDE\" =~ m/ABCF|BCDE|C(G)/; # no match, BCDE missed An alternation like this can miss input it should match, or match it on the wrong branch, so an access or filtering decision made from the result can be wrong.", "cve_priority": "medium", "cve_public_date": "2026-08-13 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Out-of-bounds heap read and write during regular", " expression matching", " - debian/patches/CVE-2026-15534_1.patch: Make super-linear cache", " countdown unsigned in regexec.c.", " - debian/patches/CVE-2026-15534_2.patch: Make superlinear cache 64-bit", " clean in regexec.c, regexp.h.", " - CVE-2026-15534", " * SECURITY UPDATE: Incorrect regular expression matches from stale", " Aho-Corasick failure flag", " - debian/patches/CVE-2026-19487.patch: Reset stale failure flag in", " Aho-Corasick prescan in regexec.c, t/re/re_tests.", " - CVE-2026-19487", "" ], "package": "perl", "version": "5.38.2-3.2ubuntu0.6", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Shafayat Hossain Majumder ", "date": "Mon, 14 Sep 2026 13:50:06 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpolkit-agent-1-0:riscv64", "from_version": { "source_package_name": "policykit-1", "source_package_version": "124-2ubuntu1.24.04.3", "version": "124-2ubuntu1.24.04.3" }, "to_version": { "source_package_name": "policykit-1", "source_package_version": "124-2ubuntu1.24.04.4", "version": "124-2ubuntu1.24.04.4" }, "cves": [ { "cve": "CVE-2026-85498", "url": "https://ubuntu.com/security/CVE-2026-85498", "cve_description": "[Regression in CVE-2026-4897 fix (polkit read_cookie()) - stack buffer underflow]", "cve_priority": "medium", "cve_public_date": "2026-09-07" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-85498", "url": "https://ubuntu.com/security/CVE-2026-85498", "cve_description": "[Regression in CVE-2026-4897 fix (polkit read_cookie()) - stack buffer underflow]", "cve_priority": "medium", "cve_public_date": "2026-09-07" } ], "log": [ "", " * SECURITY UPDATE: stack underflow in cookie input", " - debian/patches/CVE-2026-85498.patch: Unsanitized underflow in cookie", " input in src/polkitagent/polkitagenthelperprivate.c.", " - CVE-2026-85498", "" ], "package": "policykit-1", "version": "124-2ubuntu1.24.04.4", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 11 Sep 2026 13:52:30 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpolkit-gobject-1-0:riscv64", "from_version": { "source_package_name": "policykit-1", "source_package_version": "124-2ubuntu1.24.04.3", "version": "124-2ubuntu1.24.04.3" }, "to_version": { "source_package_name": "policykit-1", "source_package_version": "124-2ubuntu1.24.04.4", "version": "124-2ubuntu1.24.04.4" }, "cves": [ { "cve": "CVE-2026-85498", "url": "https://ubuntu.com/security/CVE-2026-85498", "cve_description": "[Regression in CVE-2026-4897 fix (polkit read_cookie()) - stack buffer underflow]", "cve_priority": "medium", "cve_public_date": "2026-09-07" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-85498", "url": "https://ubuntu.com/security/CVE-2026-85498", "cve_description": "[Regression in CVE-2026-4897 fix (polkit read_cookie()) - stack buffer underflow]", "cve_priority": "medium", "cve_public_date": "2026-09-07" } ], "log": [ "", " * SECURITY UPDATE: stack underflow in cookie input", " - debian/patches/CVE-2026-85498.patch: Unsanitized underflow in cookie", " input in src/polkitagent/polkitagenthelperprivate.c.", " - CVE-2026-85498", "" ], "package": "policykit-1", "version": "124-2ubuntu1.24.04.4", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 11 Sep 2026 13:52:30 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libsqlite3-0:riscv64", "from_version": { "source_package_name": "sqlite3", "source_package_version": "3.45.1-1ubuntu2.7", "version": "3.45.1-1ubuntu2.7" }, "to_version": { "source_package_name": "sqlite3", "source_package_version": "3.45.1-1ubuntu2.8", "version": "3.45.1-1ubuntu2.8" }, "cves": [ { "cve": "CVE-2026-39113", "url": "https://ubuntu.com/security/CVE-2026-39113", "cve_description": "Buffer Overflow vulnerability in SQLite affected version source snapshots/builds containing Fossil check-in 8bdc0d485e3ad0c7a1e818da66f106951d496b05cbe61d12c2c448f2f24b6d5d (Git mirror 169f68ed88b34cb68f720191c64c058f2ccec508, 2026-03-11) and later snapshots/builds allows an attacker to cause a denial of service via the ext/misc/sqlar.c, sqlarUncompressFunc(), sqlar_uncompress(), sqlite3_value_int64(), sqlite3_malloc(int), uncompress() components", "cve_priority": "medium", "cve_public_date": "2026-08-25 21:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-39113", "url": "https://ubuntu.com/security/CVE-2026-39113", "cve_description": "Buffer Overflow vulnerability in SQLite affected version source snapshots/builds containing Fossil check-in 8bdc0d485e3ad0c7a1e818da66f106951d496b05cbe61d12c2c448f2f24b6d5d (Git mirror 169f68ed88b34cb68f720191c64c058f2ccec508, 2026-03-11) and later snapshots/builds allows an attacker to cause a denial of service via the ext/misc/sqlar.c, sqlarUncompressFunc(), sqlar_uncompress(), sqlite3_value_int64(), sqlite3_malloc(int), uncompress() components", "cve_priority": "medium", "cve_public_date": "2026-08-25 21:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: buffer overflow via integer truncation in sqlar extension", " - debian/patches/CVE-2026-39113.patch: change sqlite3_value_int() to", " sqlite3_value_int64() in sqlarUncompressFunc() in ext/misc/sqlar.c to", " prevent 32-bit truncation of the decompressed size, which caused an", " undersized buffer allocation and heap buffer overflow via uncompress().", " - CVE-2026-39113", "" ], "package": "sqlite3", "version": "3.45.1-1ubuntu2.8", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Leonidas Da Silva Barbosa ", "date": "Thu, 03 Sep 2026 11:45:26 -0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "libxml2:riscv64", "from_version": { "source_package_name": "libxml2", "source_package_version": "2.9.14+dfsg-1.3ubuntu3.8", "version": "2.9.14+dfsg-1.3ubuntu3.8" }, "to_version": { "source_package_name": "libxml2", "source_package_version": "2.9.14+dfsg-1.3ubuntu3.9", "version": "2.9.14+dfsg-1.3ubuntu3.9" }, "cves": [ { "cve": "CVE-2026-86140", "url": "https://ubuntu.com/security/CVE-2026-86140", "cve_description": "In libxml2 before 2.15.4, xmlSnprintfElements in valid.c has a strcat stack-based buffer overflow.", "cve_priority": "medium", "cve_public_date": "2026-09-05 05:17:00 UTC" }, { "cve": "CVE-2026-74860", "url": "https://ubuntu.com/security/CVE-2026-74860", "cve_description": "A flaw was found in libxml2 with Python bindings enabled. A remote attacker could exploit this vulnerability by providing a specially crafted XML document containing a Document Type Definition (DTD) with enumerated attribute values. This triggers a double-free error in the SAX attributeDecl callback handler, where a string is freed twice. This flaw can lead to a denial of service (DoS) due to a reproducible crash in Python applications using the libxml2 SAX bindings.", "cve_priority": "medium", "cve_public_date": "2026-09-08 12:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-86140", "url": "https://ubuntu.com/security/CVE-2026-86140", "cve_description": "In libxml2 before 2.15.4, xmlSnprintfElements in valid.c has a strcat stack-based buffer overflow.", "cve_priority": "medium", "cve_public_date": "2026-09-05 05:17:00 UTC" }, { "cve": "CVE-2026-74860", "url": "https://ubuntu.com/security/CVE-2026-74860", "cve_description": "A flaw was found in libxml2 with Python bindings enabled. A remote attacker could exploit this vulnerability by providing a specially crafted XML document containing a Document Type Definition (DTD) with enumerated attribute values. This triggers a double-free error in the SAX attributeDecl callback handler, where a string is freed twice. This flaw can lead to a denial of service (DoS) due to a reproducible crash in Python applications using the libxml2 SAX bindings.", "cve_priority": "medium", "cve_public_date": "2026-09-08 12:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: stack-based buffer overflow in xmlSnprintfElements", " - debian/patches/CVE-2026-86140.patch: fix: add bounds checks to", " xmlSnprintfElements in valid.c in valid.c.", " - CVE-2026-86140", " * SECURITY UPDATE: double free in Python SAX attributeDecl callback", " - debian/patches/CVE-2026-74860.patch: python: Do not decref string after", " adding to the list in python/libxml.c.", " - CVE-2026-74860", "" ], "package": "libxml2", "version": "2.9.14+dfsg-1.3ubuntu3.9", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "John Breton ", "date": "Thu, 17 Sep 2026 08:09:56 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-headers-generic", "from_version": { "source_package_name": "linux-meta-riscv-7.0", "source_package_version": "7.0.0-31.31.1~24.04.1+1", "version": "7.0.0-31.31.1~24.04.1+1" }, "to_version": { "source_package_name": "linux-meta-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 7.0.0-34.34.1~24.04.1", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta-riscv-7.0", "version": "7.0.0-34.34.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Sarah Emery ", "date": "Tue, 15 Sep 2026 15:47:34 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-headers-virtual", "from_version": { "source_package_name": "linux-meta-riscv-7.0", "source_package_version": "7.0.0-31.31.1~24.04.1+1", "version": "7.0.0-31.31.1~24.04.1+1" }, "to_version": { "source_package_name": "linux-meta-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 7.0.0-34.34.1~24.04.1", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta-riscv-7.0", "version": "7.0.0-34.34.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Sarah Emery ", "date": "Tue, 15 Sep 2026 15:47:34 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta-riscv-7.0", "source_package_version": "7.0.0-31.31.1~24.04.1+1", "version": "7.0.0-31.31.1~24.04.1+1" }, "to_version": { "source_package_name": "linux-meta-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 7.0.0-34.34.1~24.04.1", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta-riscv-7.0", "version": "7.0.0-34.34.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Sarah Emery ", "date": "Tue, 15 Sep 2026 15:47:34 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-libc-dev:riscv64", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-139.139", "version": "6.8.0-139.139" }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-142.142", "version": "6.8.0-142.142" }, "cves": [ { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2165997, 1786013, 2165716 ], "changes": [ { "cves": [], "log": [ "", " * noble/linux: 6.8.0-142.142 -proposed tracker (LP: #2165997)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/s2026.08.03)", "" ], "package": "linux", "version": "6.8.0-142.142", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2165997, 1786013 ], "author": "Manuel Diewald ", "date": "Tue, 01 Sep 2026 20:33:36 +0200" }, { "cves": [ { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-140.140 -proposed tracker (LP: #2165716)", "", " * CVE-2025-10263 // CVE-2026-53354", " - arm64: errata: Mitigate TLBI errata on various Arm CPUs", " - [Config] Enable CONFIG_ARM64_ERRATUM_4118414", "", " * CVE-2025-10263", " - arm64: cputype: Add C1-Ultra definitions", " - arm64: cputype: Add C1-Premium definitions", "", " * CVE-2026-53355", " - net: rds: clear i_sends on setup unwind", "", " * CVE-2026-53186", " - RDMA/srp: bound SRP_RSP sense copy by the received length", "", " * CVE-2026-53216", " - net: mvpp2: limit XDP frame size to the RX buffer", "", " * CVE-2026-63888", " - scsi: target: iscsi: Fix CRC overread and double-free in", " iscsit_handle_text_cmd()", "", " * CVE-2026-63886", " - scsi: target: iscsi: Validate CHAP_R length before base64 decode", "", " * CVE-2026-63887", " - scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf", "", " * CVE-2026-63912", " - xfrm: esp: restore combined single-frag length gate", "", " * CVE-2026-63922", " - ipv6: exthdrs: refresh nh after handling HAO option", "", " * CVE-2026-63924", " - ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()", "", " * CVE-2026-64091", " - batman-adv: tt: fix TOCTOU race for reported vlans", "", " * CVE-2026-63984", " - ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()", "", " * CVE-2026-63992", " - tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()", "", " * CVE-2026-63993", " - vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()", "", " * CVE-2026-63994", " - tunnels: load network headers after skb_cow() in", " iptunnel_pmtud_build_icmp[v6]()", "", " * CVE-2026-64000", " - net: hsr: fix potential OOB access in supervision frame handling", "", " * CVE-2026-64007", " - netfilter: synproxy: refresh tcphdr after skb_ensure_writable", "", " * CVE-2026-53221", " - ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()", "", " * CVE-2026-53131", " - netfilter: require Ethernet MAC header before using eth_hdr()", "" ], "package": "linux", "version": "6.8.0-140.140", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2165716 ], "author": "Manuel Diewald ", "date": "Fri, 28 Aug 2026 19:42:28 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-tools-common", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-139.139", "version": "6.8.0-139.139" }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-142.142", "version": "6.8.0-142.142" }, "cves": [ { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2165997, 1786013, 2165716 ], "changes": [ { "cves": [], "log": [ "", " * noble/linux: 6.8.0-142.142 -proposed tracker (LP: #2165997)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/s2026.08.03)", "" ], "package": "linux", "version": "6.8.0-142.142", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2165997, 1786013 ], "author": "Manuel Diewald ", "date": "Tue, 01 Sep 2026 20:33:36 +0200" }, { "cves": [ { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-140.140 -proposed tracker (LP: #2165716)", "", " * CVE-2025-10263 // CVE-2026-53354", " - arm64: errata: Mitigate TLBI errata on various Arm CPUs", " - [Config] Enable CONFIG_ARM64_ERRATUM_4118414", "", " * CVE-2025-10263", " - arm64: cputype: Add C1-Ultra definitions", " - arm64: cputype: Add C1-Premium definitions", "", " * CVE-2026-53355", " - net: rds: clear i_sends on setup unwind", "", " * CVE-2026-53186", " - RDMA/srp: bound SRP_RSP sense copy by the received length", "", " * CVE-2026-53216", " - net: mvpp2: limit XDP frame size to the RX buffer", "", " * CVE-2026-63888", " - scsi: target: iscsi: Fix CRC overread and double-free in", " iscsit_handle_text_cmd()", "", " * CVE-2026-63886", " - scsi: target: iscsi: Validate CHAP_R length before base64 decode", "", " * CVE-2026-63887", " - scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf", "", " * CVE-2026-63912", " - xfrm: esp: restore combined single-frag length gate", "", " * CVE-2026-63922", " - ipv6: exthdrs: refresh nh after handling HAO option", "", " * CVE-2026-63924", " - ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()", "", " * CVE-2026-64091", " - batman-adv: tt: fix TOCTOU race for reported vlans", "", " * CVE-2026-63984", " - ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()", "", " * CVE-2026-63992", " - tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()", "", " * CVE-2026-63993", " - vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()", "", " * CVE-2026-63994", " - tunnels: load network headers after skb_cow() in", " iptunnel_pmtud_build_icmp[v6]()", "", " * CVE-2026-64000", " - net: hsr: fix potential OOB access in supervision frame handling", "", " * CVE-2026-64007", " - netfilter: synproxy: refresh tcphdr after skb_ensure_writable", "", " * CVE-2026-53221", " - ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()", "", " * CVE-2026-53131", " - netfilter: require Ethernet MAC header before using eth_hdr()", "" ], "package": "linux", "version": "6.8.0-140.140", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2165716 ], "author": "Manuel Diewald ", "date": "Fri, 28 Aug 2026 19:42:28 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-virtual", "from_version": { "source_package_name": "linux-meta-riscv-7.0", "source_package_version": "7.0.0-31.31.1~24.04.1+1", "version": "7.0.0-31.31.1~24.04.1+1" }, "to_version": { "source_package_name": "linux-meta-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 7.0.0-34.34.1~24.04.1", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta-riscv-7.0", "version": "7.0.0-34.34.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Sarah Emery ", "date": "Tue, 15 Sep 2026 15:47:34 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "netplan-generator", "from_version": { "source_package_name": "netplan.io", "source_package_version": "1.1.2-8ubuntu1~24.04.2", "version": "1.1.2-8ubuntu1~24.04.2" }, "to_version": { "source_package_name": "netplan.io", "source_package_version": "1.1.2-8ubuntu1~24.04.3", "version": "1.1.2-8ubuntu1~24.04.3" }, "cves": [], "launchpad_bugs_fixed": [ 2104373 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2104373-return-exit-code-1-on-error.patch: return exit code 1 when", " netplan exits on error (LP: #2104373)", "" ], "package": "netplan.io", "version": "1.1.2-8ubuntu1~24.04.3", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2104373 ], "author": "Guilherme Puida Moreira ", "date": "Mon, 31 Aug 2026 09:19:49 -0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "netplan.io", "from_version": { "source_package_name": "netplan.io", "source_package_version": "1.1.2-8ubuntu1~24.04.2", "version": "1.1.2-8ubuntu1~24.04.2" }, "to_version": { "source_package_name": "netplan.io", "source_package_version": "1.1.2-8ubuntu1~24.04.3", "version": "1.1.2-8ubuntu1~24.04.3" }, "cves": [], "launchpad_bugs_fixed": [ 2104373 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2104373-return-exit-code-1-on-error.patch: return exit code 1 when", " netplan exits on error (LP: #2104373)", "" ], "package": "netplan.io", "version": "1.1.2-8ubuntu1~24.04.3", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2104373 ], "author": "Guilherme Puida Moreira ", "date": "Mon, 31 Aug 2026 09:19:49 -0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "perl", "from_version": { "source_package_name": "perl", "source_package_version": "5.38.2-3.2ubuntu0.4", "version": "5.38.2-3.2ubuntu0.4" }, "to_version": { "source_package_name": "perl", "source_package_version": "5.38.2-3.2ubuntu0.6", "version": "5.38.2-3.2ubuntu0.6" }, "cves": [ { "cve": "CVE-2026-15534", "url": "https://ubuntu.com/security/CVE-2026-15534", "cve_description": "Perl versions through 5.45.1 have out-of-bounds heap reads and writes during regular expression matching via an undersized superlinear cache in S_regmatch. The regex engine's superlinear cache holds one bit per subject position for each participating WHILEM node, so the bit count is the subject length plus one times the number of nodes. Nothing checks that product for positive overflow of the signed 32-bit count: a 286331153 byte subject matched against a pattern with 15 participating nodes stores the count as 14, leaving a two byte cache. The cache is then indexed from the real match position and node number, so reads go past the end of the allocation, and on failure CACHEsayNO sets a bit past it. A caller that matches an attacker controlled subject of this size against a pattern of this shape can crash the process or corrupt heap memory.", "cve_priority": "medium", "cve_public_date": "2026-08-09 18:16:00 UTC" }, { "cve": "CVE-2026-19487", "url": "https://ubuntu.com/security/CVE-2026-19487", "cve_description": "Perl versions from 5.9.4 before 5.41.9 produce incorrect regular expression match results when a stale failure flag ends the Aho-Corasick prescan early in S_find_byclass. The prescan walks the subject for positions where the full pattern could match, and the engine tries it from the leftmost one recorded. A failing transition sets the failed flag, and a later successful transition does not clear it, so the prescan reads the stale flag as a failure and stops before it can record a candidate that starts earlier. It takes a subject where one candidate is recorded and a later character then forces a fallback through a fail link that succeeds. Example: \"ABCDE\" =~ m/ABCF|BCDE|C/; # matches C at offset 2, not BCDE \"ABCDE\" =~ m/ABCF|BCDE|C(G)/; # no match, BCDE missed An alternation like this can miss input it should match, or match it on the wrong branch, so an access or filtering decision made from the result can be wrong.", "cve_priority": "medium", "cve_public_date": "2026-08-13 16:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-15534", "url": "https://ubuntu.com/security/CVE-2026-15534", "cve_description": "Perl versions through 5.45.1 have out-of-bounds heap reads and writes during regular expression matching via an undersized superlinear cache in S_regmatch. The regex engine's superlinear cache holds one bit per subject position for each participating WHILEM node, so the bit count is the subject length plus one times the number of nodes. Nothing checks that product for positive overflow of the signed 32-bit count: a 286331153 byte subject matched against a pattern with 15 participating nodes stores the count as 14, leaving a two byte cache. The cache is then indexed from the real match position and node number, so reads go past the end of the allocation, and on failure CACHEsayNO sets a bit past it. A caller that matches an attacker controlled subject of this size against a pattern of this shape can crash the process or corrupt heap memory.", "cve_priority": "medium", "cve_public_date": "2026-08-09 18:16:00 UTC" }, { "cve": "CVE-2026-19487", "url": "https://ubuntu.com/security/CVE-2026-19487", "cve_description": "Perl versions from 5.9.4 before 5.41.9 produce incorrect regular expression match results when a stale failure flag ends the Aho-Corasick prescan early in S_find_byclass. The prescan walks the subject for positions where the full pattern could match, and the engine tries it from the leftmost one recorded. A failing transition sets the failed flag, and a later successful transition does not clear it, so the prescan reads the stale flag as a failure and stops before it can record a candidate that starts earlier. It takes a subject where one candidate is recorded and a later character then forces a fallback through a fail link that succeeds. Example: \"ABCDE\" =~ m/ABCF|BCDE|C/; # matches C at offset 2, not BCDE \"ABCDE\" =~ m/ABCF|BCDE|C(G)/; # no match, BCDE missed An alternation like this can miss input it should match, or match it on the wrong branch, so an access or filtering decision made from the result can be wrong.", "cve_priority": "medium", "cve_public_date": "2026-08-13 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Out-of-bounds heap read and write during regular", " expression matching", " - debian/patches/CVE-2026-15534_1.patch: Make super-linear cache", " countdown unsigned in regexec.c.", " - debian/patches/CVE-2026-15534_2.patch: Make superlinear cache 64-bit", " clean in regexec.c, regexp.h.", " - CVE-2026-15534", " * SECURITY UPDATE: Incorrect regular expression matches from stale", " Aho-Corasick failure flag", " - debian/patches/CVE-2026-19487.patch: Reset stale failure flag in", " Aho-Corasick prescan in regexec.c, t/re/re_tests.", " - CVE-2026-19487", "" ], "package": "perl", "version": "5.38.2-3.2ubuntu0.6", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Shafayat Hossain Majumder ", "date": "Mon, 14 Sep 2026 13:50:06 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "perl-base", "from_version": { "source_package_name": "perl", "source_package_version": "5.38.2-3.2ubuntu0.4", "version": "5.38.2-3.2ubuntu0.4" }, "to_version": { "source_package_name": "perl", "source_package_version": "5.38.2-3.2ubuntu0.6", "version": "5.38.2-3.2ubuntu0.6" }, "cves": [ { "cve": "CVE-2026-15534", "url": "https://ubuntu.com/security/CVE-2026-15534", "cve_description": "Perl versions through 5.45.1 have out-of-bounds heap reads and writes during regular expression matching via an undersized superlinear cache in S_regmatch. The regex engine's superlinear cache holds one bit per subject position for each participating WHILEM node, so the bit count is the subject length plus one times the number of nodes. Nothing checks that product for positive overflow of the signed 32-bit count: a 286331153 byte subject matched against a pattern with 15 participating nodes stores the count as 14, leaving a two byte cache. The cache is then indexed from the real match position and node number, so reads go past the end of the allocation, and on failure CACHEsayNO sets a bit past it. A caller that matches an attacker controlled subject of this size against a pattern of this shape can crash the process or corrupt heap memory.", "cve_priority": "medium", "cve_public_date": "2026-08-09 18:16:00 UTC" }, { "cve": "CVE-2026-19487", "url": "https://ubuntu.com/security/CVE-2026-19487", "cve_description": "Perl versions from 5.9.4 before 5.41.9 produce incorrect regular expression match results when a stale failure flag ends the Aho-Corasick prescan early in S_find_byclass. The prescan walks the subject for positions where the full pattern could match, and the engine tries it from the leftmost one recorded. A failing transition sets the failed flag, and a later successful transition does not clear it, so the prescan reads the stale flag as a failure and stops before it can record a candidate that starts earlier. It takes a subject where one candidate is recorded and a later character then forces a fallback through a fail link that succeeds. Example: \"ABCDE\" =~ m/ABCF|BCDE|C/; # matches C at offset 2, not BCDE \"ABCDE\" =~ m/ABCF|BCDE|C(G)/; # no match, BCDE missed An alternation like this can miss input it should match, or match it on the wrong branch, so an access or filtering decision made from the result can be wrong.", "cve_priority": "medium", "cve_public_date": "2026-08-13 16:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-15534", "url": "https://ubuntu.com/security/CVE-2026-15534", "cve_description": "Perl versions through 5.45.1 have out-of-bounds heap reads and writes during regular expression matching via an undersized superlinear cache in S_regmatch. The regex engine's superlinear cache holds one bit per subject position for each participating WHILEM node, so the bit count is the subject length plus one times the number of nodes. Nothing checks that product for positive overflow of the signed 32-bit count: a 286331153 byte subject matched against a pattern with 15 participating nodes stores the count as 14, leaving a two byte cache. The cache is then indexed from the real match position and node number, so reads go past the end of the allocation, and on failure CACHEsayNO sets a bit past it. A caller that matches an attacker controlled subject of this size against a pattern of this shape can crash the process or corrupt heap memory.", "cve_priority": "medium", "cve_public_date": "2026-08-09 18:16:00 UTC" }, { "cve": "CVE-2026-19487", "url": "https://ubuntu.com/security/CVE-2026-19487", "cve_description": "Perl versions from 5.9.4 before 5.41.9 produce incorrect regular expression match results when a stale failure flag ends the Aho-Corasick prescan early in S_find_byclass. The prescan walks the subject for positions where the full pattern could match, and the engine tries it from the leftmost one recorded. A failing transition sets the failed flag, and a later successful transition does not clear it, so the prescan reads the stale flag as a failure and stops before it can record a candidate that starts earlier. It takes a subject where one candidate is recorded and a later character then forces a fallback through a fail link that succeeds. Example: \"ABCDE\" =~ m/ABCF|BCDE|C/; # matches C at offset 2, not BCDE \"ABCDE\" =~ m/ABCF|BCDE|C(G)/; # no match, BCDE missed An alternation like this can miss input it should match, or match it on the wrong branch, so an access or filtering decision made from the result can be wrong.", "cve_priority": "medium", "cve_public_date": "2026-08-13 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Out-of-bounds heap read and write during regular", " expression matching", " - debian/patches/CVE-2026-15534_1.patch: Make super-linear cache", " countdown unsigned in regexec.c.", " - debian/patches/CVE-2026-15534_2.patch: Make superlinear cache 64-bit", " clean in regexec.c, regexp.h.", " - CVE-2026-15534", " * SECURITY UPDATE: Incorrect regular expression matches from stale", " Aho-Corasick failure flag", " - debian/patches/CVE-2026-19487.patch: Reset stale failure flag in", " Aho-Corasick prescan in regexec.c, t/re/re_tests.", " - CVE-2026-19487", "" ], "package": "perl", "version": "5.38.2-3.2ubuntu0.6", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Shafayat Hossain Majumder ", "date": "Mon, 14 Sep 2026 13:50:06 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "perl-modules-5.38", "from_version": { "source_package_name": "perl", "source_package_version": "5.38.2-3.2ubuntu0.4", "version": "5.38.2-3.2ubuntu0.4" }, "to_version": { "source_package_name": "perl", "source_package_version": "5.38.2-3.2ubuntu0.6", "version": "5.38.2-3.2ubuntu0.6" }, "cves": [ { "cve": "CVE-2026-15534", "url": "https://ubuntu.com/security/CVE-2026-15534", "cve_description": "Perl versions through 5.45.1 have out-of-bounds heap reads and writes during regular expression matching via an undersized superlinear cache in S_regmatch. The regex engine's superlinear cache holds one bit per subject position for each participating WHILEM node, so the bit count is the subject length plus one times the number of nodes. Nothing checks that product for positive overflow of the signed 32-bit count: a 286331153 byte subject matched against a pattern with 15 participating nodes stores the count as 14, leaving a two byte cache. The cache is then indexed from the real match position and node number, so reads go past the end of the allocation, and on failure CACHEsayNO sets a bit past it. A caller that matches an attacker controlled subject of this size against a pattern of this shape can crash the process or corrupt heap memory.", "cve_priority": "medium", "cve_public_date": "2026-08-09 18:16:00 UTC" }, { "cve": "CVE-2026-19487", "url": "https://ubuntu.com/security/CVE-2026-19487", "cve_description": "Perl versions from 5.9.4 before 5.41.9 produce incorrect regular expression match results when a stale failure flag ends the Aho-Corasick prescan early in S_find_byclass. The prescan walks the subject for positions where the full pattern could match, and the engine tries it from the leftmost one recorded. A failing transition sets the failed flag, and a later successful transition does not clear it, so the prescan reads the stale flag as a failure and stops before it can record a candidate that starts earlier. It takes a subject where one candidate is recorded and a later character then forces a fallback through a fail link that succeeds. Example: \"ABCDE\" =~ m/ABCF|BCDE|C/; # matches C at offset 2, not BCDE \"ABCDE\" =~ m/ABCF|BCDE|C(G)/; # no match, BCDE missed An alternation like this can miss input it should match, or match it on the wrong branch, so an access or filtering decision made from the result can be wrong.", "cve_priority": "medium", "cve_public_date": "2026-08-13 16:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-15534", "url": "https://ubuntu.com/security/CVE-2026-15534", "cve_description": "Perl versions through 5.45.1 have out-of-bounds heap reads and writes during regular expression matching via an undersized superlinear cache in S_regmatch. The regex engine's superlinear cache holds one bit per subject position for each participating WHILEM node, so the bit count is the subject length plus one times the number of nodes. Nothing checks that product for positive overflow of the signed 32-bit count: a 286331153 byte subject matched against a pattern with 15 participating nodes stores the count as 14, leaving a two byte cache. The cache is then indexed from the real match position and node number, so reads go past the end of the allocation, and on failure CACHEsayNO sets a bit past it. A caller that matches an attacker controlled subject of this size against a pattern of this shape can crash the process or corrupt heap memory.", "cve_priority": "medium", "cve_public_date": "2026-08-09 18:16:00 UTC" }, { "cve": "CVE-2026-19487", "url": "https://ubuntu.com/security/CVE-2026-19487", "cve_description": "Perl versions from 5.9.4 before 5.41.9 produce incorrect regular expression match results when a stale failure flag ends the Aho-Corasick prescan early in S_find_byclass. The prescan walks the subject for positions where the full pattern could match, and the engine tries it from the leftmost one recorded. A failing transition sets the failed flag, and a later successful transition does not clear it, so the prescan reads the stale flag as a failure and stops before it can record a candidate that starts earlier. It takes a subject where one candidate is recorded and a later character then forces a fallback through a fail link that succeeds. Example: \"ABCDE\" =~ m/ABCF|BCDE|C/; # matches C at offset 2, not BCDE \"ABCDE\" =~ m/ABCF|BCDE|C(G)/; # no match, BCDE missed An alternation like this can miss input it should match, or match it on the wrong branch, so an access or filtering decision made from the result can be wrong.", "cve_priority": "medium", "cve_public_date": "2026-08-13 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Out-of-bounds heap read and write during regular", " expression matching", " - debian/patches/CVE-2026-15534_1.patch: Make super-linear cache", " countdown unsigned in regexec.c.", " - debian/patches/CVE-2026-15534_2.patch: Make superlinear cache 64-bit", " clean in regexec.c, regexp.h.", " - CVE-2026-15534", " * SECURITY UPDATE: Incorrect regular expression matches from stale", " Aho-Corasick failure flag", " - debian/patches/CVE-2026-19487.patch: Reset stale failure flag in", " Aho-Corasick prescan in regexec.c, t/re/re_tests.", " - CVE-2026-19487", "" ], "package": "perl", "version": "5.38.2-3.2ubuntu0.6", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Shafayat Hossain Majumder ", "date": "Mon, 14 Sep 2026 13:50:06 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "polkitd", "from_version": { "source_package_name": "policykit-1", "source_package_version": "124-2ubuntu1.24.04.3", "version": "124-2ubuntu1.24.04.3" }, "to_version": { "source_package_name": "policykit-1", "source_package_version": "124-2ubuntu1.24.04.4", "version": "124-2ubuntu1.24.04.4" }, "cves": [ { "cve": "CVE-2026-85498", "url": "https://ubuntu.com/security/CVE-2026-85498", "cve_description": "[Regression in CVE-2026-4897 fix (polkit read_cookie()) - stack buffer underflow]", "cve_priority": "medium", "cve_public_date": "2026-09-07" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-85498", "url": "https://ubuntu.com/security/CVE-2026-85498", "cve_description": "[Regression in CVE-2026-4897 fix (polkit read_cookie()) - stack buffer underflow]", "cve_priority": "medium", "cve_public_date": "2026-09-07" } ], "log": [ "", " * SECURITY UPDATE: stack underflow in cookie input", " - debian/patches/CVE-2026-85498.patch: Unsanitized underflow in cookie", " input in src/polkitagent/polkitagenthelperprivate.c.", " - CVE-2026-85498", "" ], "package": "policykit-1", "version": "124-2ubuntu1.24.04.4", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 11 Sep 2026 13:52:30 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-netplan", "from_version": { "source_package_name": "netplan.io", "source_package_version": "1.1.2-8ubuntu1~24.04.2", "version": "1.1.2-8ubuntu1~24.04.2" }, "to_version": { "source_package_name": "netplan.io", "source_package_version": "1.1.2-8ubuntu1~24.04.3", "version": "1.1.2-8ubuntu1~24.04.3" }, "cves": [], "launchpad_bugs_fixed": [ 2104373 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2104373-return-exit-code-1-on-error.patch: return exit code 1 when", " netplan exits on error (LP: #2104373)", "" ], "package": "netplan.io", "version": "1.1.2-8ubuntu1~24.04.3", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2104373 ], "author": "Guilherme Puida Moreira ", "date": "Mon, 31 Aug 2026 09:19:49 -0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "rsyslog", "from_version": { "source_package_name": "rsyslog", "source_package_version": "8.2312.0-3ubuntu9.3", "version": "8.2312.0-3ubuntu9.3" }, "to_version": { "source_package_name": "rsyslog", "source_package_version": "8.2312.0-3ubuntu9.4", "version": "8.2312.0-3ubuntu9.4" }, "cves": [ { "cve": "CVE-2026-78002", "url": "https://ubuntu.com/security/CVE-2026-78002", "cve_description": "A flaw was found in rsyslog. An unauthenticated remote attacker can trigger a heap buffer overflow in the RainerScript `replace()` function by sending specially crafted syslog messages. This vulnerability arises from an incorrect buffer size calculation during string replacement, causing memory corruption. Successful exploitation can lead to a denial of service (DoS) for the affected system.", "cve_priority": "medium", "cve_public_date": "2026-08-27 17:20:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-78002", "url": "https://ubuntu.com/security/CVE-2026-78002", "cve_description": "A flaw was found in rsyslog. An unauthenticated remote attacker can trigger a heap buffer overflow in the RainerScript `replace()` function by sending specially crafted syslog messages. This vulnerability arises from an incorrect buffer size calculation during string replacement, causing memory corruption. Successful exploitation can lead to a denial of service (DoS) for the affected system.", "cve_priority": "medium", "cve_public_date": "2026-08-27 17:20:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Denial of Service", " - debian/patches/CVE-2026-78002.patch: rainerscript: align replace sizing", " rewind in grammar/rainerscript.c.", " - CVE-2026-78002", "" ], "package": "rsyslog", "version": "8.2312.0-3ubuntu9.4", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "John Breton ", "date": "Wed, 16 Sep 2026 12:42:27 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "sudo", "from_version": { "source_package_name": "sudo", "source_package_version": "1.9.15p5-3ubuntu5.24.04.2", "version": "1.9.15p5-3ubuntu5.24.04.2" }, "to_version": { "source_package_name": "sudo", "source_package_version": "1.9.15p5-3ubuntu5.24.04.3", "version": "1.9.15p5-3ubuntu5.24.04.3" }, "cves": [ { "cve": "CVE-2026-82474", "url": "https://ubuntu.com/security/CVE-2026-82474", "cve_description": "Sudo through 1.9.17p2 fails to apply intercept policy checks to the execveat system call in ptrace-based intercept mode. Users permitted to run specific commands can execute denied programs by calling execveat directly or through fexecve, bypassing policy enforcement and logging.", "cve_priority": "medium", "cve_public_date": "2026-08-29 17:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-82474", "url": "https://ubuntu.com/security/CVE-2026-82474", "cve_description": "Sudo through 1.9.17p2 fails to apply intercept policy checks to the execveat system call in ptrace-based intercept mode. Users permitted to run specific commands can execute denied programs by calling execveat directly or through fexecve, bypassing policy enforcement and logging.", "cve_priority": "medium", "cve_public_date": "2026-08-29 17:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: intercept and log_subcmds bypass via execveat(2)", " - debian/patches/CVE-2026-82474-pre1.patch: resolve /proc/self/fd/N", " pathname in get_execve_info().", " - debian/patches/CVE-2026-82474-pre2.patch: pass correct name to", " proc_read_link().", " - debian/patches/CVE-2026-82474.patch: add intercept and log_subcmds", " support for execveat(2).", " - debian/patches/CVE-2026-82474-2.patch: error out if we run out of", " space rewriting pathname.", " - debian/patches/CVE-2026-82474-3.patch: fix handling of relative paths", " in the execveat(2) intercept support.", " - CVE-2026-82474", "" ], "package": "sudo", "version": "1.9.15p5-3ubuntu5.24.04.3", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "John Breton ", "date": "Mon, 21 Sep 2026 14:37:45 -0400" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-headers-7.0.0-34-generic", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-31.31.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "cves": [ { "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": [ 2165773, 1786013, 2165774, 2165995, 2165777 ], "changes": [ { "cves": [ { "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": [ "", " * noble/linux-riscv-7.0: 7.0.0-34.34.1~24.04.1 -proposed tracker (LP: #2165773)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv-7.0/dkms-versions -- update from kernel-", " versions (main/s2026.08.03)", "", " [ Ubuntu-riscv: 7.0.0-34.34.1 ]", "", " * resolute/linux-riscv: 7.0.0-34.34.1 -proposed tracker (LP: #2165774)", " [ Ubuntu: 7.0.0-34.34 ]", " * resolute/linux: 7.0.0-34.34 -proposed tracker (LP: #2165995)", " [ Ubuntu: 7.0.0-32.32 ]", " * resolute/linux: 7.0.0-32.32 -proposed tracker (LP: #2165777)", " * 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-riscv-7.0", "version": "7.0.0-34.34.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2165773, 1786013, 2165774, 2165995, 2165777 ], "author": "Sarah Emery ", "date": "Tue, 15 Sep 2026 14:59:56 +0200" } ], "notes": "linux-headers-7.0.0-34-generic version '7.0.0-34.34.1~24.04.1' (source package linux-riscv-7.0 version '7.0.0-34.34.1~24.04.1') was added. linux-headers-7.0.0-34-generic version '7.0.0-34.34.1~24.04.1' has the same source package name, linux-riscv-7.0, as removed package linux-headers-7.0.0-31-generic. As such we can use the source package version of the removed package, '7.0.0-31.31.1~24.04.1', 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-image-7.0.0-34-generic", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-31.31.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "cves": [ { "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": [ 2165773, 1786013, 2165774, 2165995, 2165777 ], "changes": [ { "cves": [ { "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": [ "", " * noble/linux-riscv-7.0: 7.0.0-34.34.1~24.04.1 -proposed tracker (LP: #2165773)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv-7.0/dkms-versions -- update from kernel-", " versions (main/s2026.08.03)", "", " [ Ubuntu-riscv: 7.0.0-34.34.1 ]", "", " * resolute/linux-riscv: 7.0.0-34.34.1 -proposed tracker (LP: #2165774)", " [ Ubuntu: 7.0.0-34.34 ]", " * resolute/linux: 7.0.0-34.34 -proposed tracker (LP: #2165995)", " [ Ubuntu: 7.0.0-32.32 ]", " * resolute/linux: 7.0.0-32.32 -proposed tracker (LP: #2165777)", " * 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-riscv-7.0", "version": "7.0.0-34.34.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2165773, 1786013, 2165774, 2165995, 2165777 ], "author": "Sarah Emery ", "date": "Tue, 15 Sep 2026 14:59:56 +0200" } ], "notes": "linux-image-7.0.0-34-generic version '7.0.0-34.34.1~24.04.1' (source package linux-riscv-7.0 version '7.0.0-34.34.1~24.04.1') was added. linux-image-7.0.0-34-generic version '7.0.0-34.34.1~24.04.1' has the same source package name, linux-riscv-7.0, as removed package linux-headers-7.0.0-31-generic. As such we can use the source package version of the removed package, '7.0.0-31.31.1~24.04.1', 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-34-generic", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-31.31.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "cves": [ { "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": [ 2165773, 1786013, 2165774, 2165995, 2165777 ], "changes": [ { "cves": [ { "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": [ "", " * noble/linux-riscv-7.0: 7.0.0-34.34.1~24.04.1 -proposed tracker (LP: #2165773)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv-7.0/dkms-versions -- update from kernel-", " versions (main/s2026.08.03)", "", " [ Ubuntu-riscv: 7.0.0-34.34.1 ]", "", " * resolute/linux-riscv: 7.0.0-34.34.1 -proposed tracker (LP: #2165774)", " [ Ubuntu: 7.0.0-34.34 ]", " * resolute/linux: 7.0.0-34.34 -proposed tracker (LP: #2165995)", " [ Ubuntu: 7.0.0-32.32 ]", " * resolute/linux: 7.0.0-32.32 -proposed tracker (LP: #2165777)", " * 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-riscv-7.0", "version": "7.0.0-34.34.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2165773, 1786013, 2165774, 2165995, 2165777 ], "author": "Sarah Emery ", "date": "Tue, 15 Sep 2026 14:59:56 +0200" } ], "notes": "linux-modules-7.0.0-34-generic version '7.0.0-34.34.1~24.04.1' (source package linux-riscv-7.0 version '7.0.0-34.34.1~24.04.1') was added. linux-modules-7.0.0-34-generic version '7.0.0-34.34.1~24.04.1' has the same source package name, linux-riscv-7.0, as removed package linux-headers-7.0.0-31-generic. As such we can use the source package version of the removed package, '7.0.0-31.31.1~24.04.1', 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-riscv-7.0-headers-7.0.0-34", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-31.31.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "cves": [ { "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": [ 2165773, 1786013, 2165774, 2165995, 2165777 ], "changes": [ { "cves": [ { "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": [ "", " * noble/linux-riscv-7.0: 7.0.0-34.34.1~24.04.1 -proposed tracker (LP: #2165773)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv-7.0/dkms-versions -- update from kernel-", " versions (main/s2026.08.03)", "", " [ Ubuntu-riscv: 7.0.0-34.34.1 ]", "", " * resolute/linux-riscv: 7.0.0-34.34.1 -proposed tracker (LP: #2165774)", " [ Ubuntu: 7.0.0-34.34 ]", " * resolute/linux: 7.0.0-34.34 -proposed tracker (LP: #2165995)", " [ Ubuntu: 7.0.0-32.32 ]", " * resolute/linux: 7.0.0-32.32 -proposed tracker (LP: #2165777)", " * 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-riscv-7.0", "version": "7.0.0-34.34.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2165773, 1786013, 2165774, 2165995, 2165777 ], "author": "Sarah Emery ", "date": "Tue, 15 Sep 2026 14:59:56 +0200" } ], "notes": "linux-riscv-7.0-headers-7.0.0-34 version '7.0.0-34.34.1~24.04.1' (source package linux-riscv-7.0 version '7.0.0-34.34.1~24.04.1') was added. linux-riscv-7.0-headers-7.0.0-34 version '7.0.0-34.34.1~24.04.1' has the same source package name, linux-riscv-7.0, as removed package linux-headers-7.0.0-31-generic. As such we can use the source package version of the removed package, '7.0.0-31.31.1~24.04.1', 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-riscv-7.0-tools-7.0.0-34", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-31.31.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "cves": [ { "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": [ 2165773, 1786013, 2165774, 2165995, 2165777 ], "changes": [ { "cves": [ { "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": [ "", " * noble/linux-riscv-7.0: 7.0.0-34.34.1~24.04.1 -proposed tracker (LP: #2165773)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv-7.0/dkms-versions -- update from kernel-", " versions (main/s2026.08.03)", "", " [ Ubuntu-riscv: 7.0.0-34.34.1 ]", "", " * resolute/linux-riscv: 7.0.0-34.34.1 -proposed tracker (LP: #2165774)", " [ Ubuntu: 7.0.0-34.34 ]", " * resolute/linux: 7.0.0-34.34 -proposed tracker (LP: #2165995)", " [ Ubuntu: 7.0.0-32.32 ]", " * resolute/linux: 7.0.0-32.32 -proposed tracker (LP: #2165777)", " * 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-riscv-7.0", "version": "7.0.0-34.34.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2165773, 1786013, 2165774, 2165995, 2165777 ], "author": "Sarah Emery ", "date": "Tue, 15 Sep 2026 14:59:56 +0200" } ], "notes": "linux-riscv-7.0-tools-7.0.0-34 version '7.0.0-34.34.1~24.04.1' (source package linux-riscv-7.0 version '7.0.0-34.34.1~24.04.1') was added. linux-riscv-7.0-tools-7.0.0-34 version '7.0.0-34.34.1~24.04.1' has the same source package name, linux-riscv-7.0, as removed package linux-headers-7.0.0-31-generic. As such we can use the source package version of the removed package, '7.0.0-31.31.1~24.04.1', 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-tools-7.0.0-34-generic", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-31.31.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "cves": [ { "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": [ 2165773, 1786013, 2165774, 2165995, 2165777 ], "changes": [ { "cves": [ { "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": [ "", " * noble/linux-riscv-7.0: 7.0.0-34.34.1~24.04.1 -proposed tracker (LP: #2165773)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv-7.0/dkms-versions -- update from kernel-", " versions (main/s2026.08.03)", "", " [ Ubuntu-riscv: 7.0.0-34.34.1 ]", "", " * resolute/linux-riscv: 7.0.0-34.34.1 -proposed tracker (LP: #2165774)", " [ Ubuntu: 7.0.0-34.34 ]", " * resolute/linux: 7.0.0-34.34 -proposed tracker (LP: #2165995)", " [ Ubuntu: 7.0.0-32.32 ]", " * resolute/linux: 7.0.0-32.32 -proposed tracker (LP: #2165777)", " * 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-riscv-7.0", "version": "7.0.0-34.34.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2165773, 1786013, 2165774, 2165995, 2165777 ], "author": "Sarah Emery ", "date": "Tue, 15 Sep 2026 14:59:56 +0200" } ], "notes": "linux-tools-7.0.0-34-generic version '7.0.0-34.34.1~24.04.1' (source package linux-riscv-7.0 version '7.0.0-34.34.1~24.04.1') was added. linux-tools-7.0.0-34-generic version '7.0.0-34.34.1~24.04.1' has the same source package name, linux-riscv-7.0, as removed package linux-headers-7.0.0-31-generic. As such we can use the source package version of the removed package, '7.0.0-31.31.1~24.04.1', 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-headers-7.0.0-31-generic", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-31.31.1~24.04.1", "version": "7.0.0-31.31.1~24.04.1" }, "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-image-7.0.0-31-generic", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-31.31.1~24.04.1", "version": "7.0.0-31.31.1~24.04.1" }, "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-31-generic", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-31.31.1~24.04.1", "version": "7.0.0-31.31.1~24.04.1" }, "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-riscv-7.0-headers-7.0.0-31", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-31.31.1~24.04.1", "version": "7.0.0-31.31.1~24.04.1" }, "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-riscv-7.0-tools-7.0.0-31", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-31.31.1~24.04.1", "version": "7.0.0-31.31.1~24.04.1" }, "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-tools-7.0.0-31-generic", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-31.31.1~24.04.1", "version": "7.0.0-31.31.1~24.04.1" }, "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 24.04 noble image from release image serial 20260911 to 20260926", "from_series": "noble", "to_series": "noble", "from_serial": "20260911", "to_serial": "20260926", "from_manifest_filename": "release_manifest.previous", "to_manifest_filename": "manifest.current" }