{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-image-6.8.0-146-generic", "linux-modules-6.8.0-146-generic" ], "removed": [ "linux-image-6.8.0-139-generic", "linux-modules-6.8.0-139-generic" ], "diff": [ "apparmor", "base-files", "curl", "gir1.2-glib-2.0", "libapparmor1", "libaudit-common", "libaudit1", "libc-bin", "libc6", "libcurl4t64", "libexpat1", "libglib2.0-0t64", "libgssapi-krb5-2", "libk5crypto3", "libkrb5-3", "libkrb5support0", "libnetplan1", "libpython3.12-minimal", "libpython3.12-stdlib", "libsqlite3-0", "libssl3t64", "linux-image-virtual", "netplan-generator", "netplan.io", "openssl", "perl-base", "python-apt-common", "python3-apt", "python3-distupgrade", "python3-jwt", "python3-netplan", "python3-requests", "python3.12", "python3.12-minimal", "sudo", "ubuntu-release-upgrader-core" ] } }, "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": "base-files", "from_version": { "source_package_name": "base-files", "source_package_version": "13ubuntu10.4", "version": "13ubuntu10.4" }, "to_version": { "source_package_name": "base-files", "source_package_version": "13ubuntu10.5", "version": "13ubuntu10.5" }, "cves": [], "launchpad_bugs_fixed": [ 2166604 ], "changes": [ { "cves": [], "log": [ "", " * /etc/issue{,.net}, /etc/{lsb,os}-release: bump version to 24.04.5", " (LP: #2166604)", "" ], "package": "base-files", "version": "13ubuntu10.5", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2166604 ], "author": "Graham Inggs ", "date": "Sun, 06 Sep 2026 14:29:43 +0000" } ], "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": "gir1.2-glib-2.0", "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": "libapparmor1", "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", "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": "libc-bin", "from_version": { "source_package_name": "glibc", "source_package_version": "2.39-0ubuntu8.8", "version": "2.39-0ubuntu8.8" }, "to_version": { "source_package_name": "glibc", "source_package_version": "2.39-0ubuntu8.9", "version": "2.39-0ubuntu8.9" }, "cves": [ { "cve": "CVE-2026-19499", "url": "https://ubuntu.com/security/CVE-2026-19499", "cve_description": "Calling strfmon and strfmon_l in the GNU C Library version 2.38 to 2.44 can write past the end of the caller-supplied output buffer when a conversion uses right-justified width padding. Exploitation requires an application code path that calls strfmon or strfmon_l with right-justified width padding into a destination buffer that is large enough for the padding to succeed but too small for the internal memmove call. The field width or format may be attacker-influenced or a fixed susceptible pattern in the caller. At the time of publication, no network-facing application impact is known.", "cve_priority": "medium", "cve_public_date": "2026-09-14 18:17:00 UTC" }, { "cve": "CVE-2026-19542", "url": "https://ubuntu.com/security/CVE-2026-19542", "cve_description": "Calling tdelete on a sufficiently deep tree in the GNU C Library version 2.1 to 2.44 may write one pointer past the end of an alloca-allocated array on the stack, which may crash the application. The tdelete implementation keeps an explicit stack of parent nodes for rebalancing, which is grown as needed while descending the tree. Two rebalancing branches push an additional entry without checking the capacity, and write past the array when the stack is exactly full. Triggering this requires a node at a depth of exactly 40 (or 40 plus a multiple of 20), which implies a tree with at least a million nodes, so an attacker must drive a large number of insertions and deletions through an application that uses tsearch and tdelete. The written value is a pointer into a tree node and is not directly attacker controlled. No affected application in common distributions has been identified.", "cve_priority": "medium", "cve_public_date": "2026-09-14 18:17:00 UTC" }, { "cve": "CVE-2026-6368", "url": "https://ubuntu.com/security/CVE-2026-6368", "cve_description": "Calling wordexp with WRDE_APPEND in the GNU C Library version 2.0 to version 2.43 can cause the interface to return invalid memory in the we_wordv member, which on subsequent calls to wordfree may abort the process.", "cve_priority": "medium", "cve_public_date": "2026-08-10 19:17:00 UTC" }, { "cve": "CVE-2026-6791", "url": "https://ubuntu.com/security/CVE-2026-6791", "cve_description": "When expanding paths that begin with a tilde (~) followed by a username, the internal parse_tilde function extracts the username to determine the user's home directory. The implementation allocates memory for this username directly on the stack using the strndupa macro. Because the size of this allocation was determined by the length of the user-supplied input without any bounds checks, passing an excessively long username e.g. thousands of characters, forces the thread to exhaust its stack space. Thus if an application passes untrusted, attacker-controlled input to the wordexp function, an attacker can trigger a stack clash.", "cve_priority": "medium", "cve_public_date": "2026-08-10 19:17:00 UTC" }, { "cve": "CVE-2026-77117", "url": "https://ubuntu.com/security/CVE-2026-77117", "cve_description": "Converting crafted SHIFT_JISX0213 input to UCS-4 or the internal wide character encoding, for example with iconv, in the GNU C Library version 2.3 to 2.44 may result in the converter making no progress, causing the calling application to hang. Some SHIFT_JISX0213 sequences decode to two code points. If the output buffer has room for only the first one, the converter stores the second in the conversion state and returns E2BIG, but it never clears that pending character after emitting it on the next call. The converter then keeps emitting the pending character without consuming further input, so an application that retries the conversion loops forever. The input must be attacker controlled and the application must convert it with an output buffer small enough to split the two code points. Only the SHIFT_JISX0213 character set is affected, which is not commonly used. The related defect in the EUC_JISX0213 converter is tracked separately as CVE-2026-80489.", "cve_priority": "medium", "cve_public_date": "2026-09-15 11:17:00 UTC" }, { "cve": "CVE-2026-80489", "url": "https://ubuntu.com/security/CVE-2026-80489", "cve_description": "Converting crafted EUC_JISX0213 input to UCS-4 or the internal wide character encoding, for example with iconv, in the GNU C Library version 2.3 to 2.44 may result in the converter making no progress, causing the calling application to hang. Some EUC_JISX0213 sequences decode to two code points. If the output buffer has room for only the first one, the converter stores the second in the conversion state and returns E2BIG, but it never clears that pending character after emitting it on the next call. The converter then keeps emitting the pending character without consuming further input, so an application that retries the conversion loops forever. The input must be attacker controlled and the application must convert it with an output buffer small enough to split the two code points. Only the EUC_JISX0213 character set is affected, which is not commonly used. The related defect in SHIFT_JISX0213 converter is tracked separately as CVE-2026-77117.", "cve_priority": "medium", "cve_public_date": "2026-09-15 11:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-19499", "url": "https://ubuntu.com/security/CVE-2026-19499", "cve_description": "Calling strfmon and strfmon_l in the GNU C Library version 2.38 to 2.44 can write past the end of the caller-supplied output buffer when a conversion uses right-justified width padding. Exploitation requires an application code path that calls strfmon or strfmon_l with right-justified width padding into a destination buffer that is large enough for the padding to succeed but too small for the internal memmove call. The field width or format may be attacker-influenced or a fixed susceptible pattern in the caller. At the time of publication, no network-facing application impact is known.", "cve_priority": "medium", "cve_public_date": "2026-09-14 18:17:00 UTC" }, { "cve": "CVE-2026-19542", "url": "https://ubuntu.com/security/CVE-2026-19542", "cve_description": "Calling tdelete on a sufficiently deep tree in the GNU C Library version 2.1 to 2.44 may write one pointer past the end of an alloca-allocated array on the stack, which may crash the application. The tdelete implementation keeps an explicit stack of parent nodes for rebalancing, which is grown as needed while descending the tree. Two rebalancing branches push an additional entry without checking the capacity, and write past the array when the stack is exactly full. Triggering this requires a node at a depth of exactly 40 (or 40 plus a multiple of 20), which implies a tree with at least a million nodes, so an attacker must drive a large number of insertions and deletions through an application that uses tsearch and tdelete. The written value is a pointer into a tree node and is not directly attacker controlled. No affected application in common distributions has been identified.", "cve_priority": "medium", "cve_public_date": "2026-09-14 18:17:00 UTC" }, { "cve": "CVE-2026-6368", "url": "https://ubuntu.com/security/CVE-2026-6368", "cve_description": "Calling wordexp with WRDE_APPEND in the GNU C Library version 2.0 to version 2.43 can cause the interface to return invalid memory in the we_wordv member, which on subsequent calls to wordfree may abort the process.", "cve_priority": "medium", "cve_public_date": "2026-08-10 19:17:00 UTC" }, { "cve": "CVE-2026-6791", "url": "https://ubuntu.com/security/CVE-2026-6791", "cve_description": "When expanding paths that begin with a tilde (~) followed by a username, the internal parse_tilde function extracts the username to determine the user's home directory. The implementation allocates memory for this username directly on the stack using the strndupa macro. Because the size of this allocation was determined by the length of the user-supplied input without any bounds checks, passing an excessively long username e.g. thousands of characters, forces the thread to exhaust its stack space. Thus if an application passes untrusted, attacker-controlled input to the wordexp function, an attacker can trigger a stack clash.", "cve_priority": "medium", "cve_public_date": "2026-08-10 19:17:00 UTC" }, { "cve": "CVE-2026-77117", "url": "https://ubuntu.com/security/CVE-2026-77117", "cve_description": "Converting crafted SHIFT_JISX0213 input to UCS-4 or the internal wide character encoding, for example with iconv, in the GNU C Library version 2.3 to 2.44 may result in the converter making no progress, causing the calling application to hang. Some SHIFT_JISX0213 sequences decode to two code points. If the output buffer has room for only the first one, the converter stores the second in the conversion state and returns E2BIG, but it never clears that pending character after emitting it on the next call. The converter then keeps emitting the pending character without consuming further input, so an application that retries the conversion loops forever. The input must be attacker controlled and the application must convert it with an output buffer small enough to split the two code points. Only the SHIFT_JISX0213 character set is affected, which is not commonly used. The related defect in the EUC_JISX0213 converter is tracked separately as CVE-2026-80489.", "cve_priority": "medium", "cve_public_date": "2026-09-15 11:17:00 UTC" }, { "cve": "CVE-2026-80489", "url": "https://ubuntu.com/security/CVE-2026-80489", "cve_description": "Converting crafted EUC_JISX0213 input to UCS-4 or the internal wide character encoding, for example with iconv, in the GNU C Library version 2.3 to 2.44 may result in the converter making no progress, causing the calling application to hang. Some EUC_JISX0213 sequences decode to two code points. If the output buffer has room for only the first one, the converter stores the second in the conversion state and returns E2BIG, but it never clears that pending character after emitting it on the next call. The converter then keeps emitting the pending character without consuming further input, so an application that retries the conversion loops forever. The input must be attacker controlled and the application must convert it with an output buffer small enough to split the two code points. Only the EUC_JISX0213 character set is affected, which is not commonly used. The related defect in SHIFT_JISX0213 converter is tracked separately as CVE-2026-77117.", "cve_priority": "medium", "cve_public_date": "2026-09-15 11:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer overflow in strfmon right-justification padding", " - debian/patches/CVE-2026-19499.patch: stdlib: Fix right-justification in", " strfmon (bug 34510, CVE-2026-19499) in stdlib/Makefile,", " stdlib/strfmon_l.c, stdlib/tst-strfmon-bug34510.c.", " - CVE-2026-19499", " * SECURITY UPDATE: Out-of-bounds stack array access in tdelete", " - debian/patches/CVE-2026-19542.patch: misc: Fix out-of-bounds array write", " in tdelete (bug 34506) in misc/tsearch.c.", " - CVE-2026-19542", " * SECURITY UPDATE: invalid memory when calling wordexp with WRDE_APPEND", " - debian/patches/CVE-2026-6368.patch: posix: Fix wordexp WRDE_APPEND to", " preserve state on non-NOSPACE errors (BZ 34090, CVE-2026-6368) in", " posix/Makefile, posix/tst-wordexp-append.c, posix/wordexp.c.", " - CVE-2026-6368", " * SECURITY UPDATE: stack clash issue when expanding long tilde paths", " - debian/patches/CVE-2026-6791.patch: posix: Fix stack overflow in wordexp", " tilde expansion (BZ 34091, CVE-2026-6791) in posix/Makefile, posix/tst-", " wordexp-tilde.c, posix/tst-wordexp-tilde.root/etc/group, posix/tst-", " wordexp-tilde.root/etc/nsswitch.conf, posix/tst-wordexp-", " tilde.root/etc/passwd, posix/wordexp.c.", " - CVE-2026-6791", " * SECURITY UPDATE: SHIFT_JISX0213 converter hang", " - debian/patches/CVE-2026-77117-1.patch: iconvdata: SHIFT_JISX0213 decoding", " lacks pending character reset (CVE-2026-77117) in", " iconvdata/shift_jisx0213.c.", " - debian/patches/CVE-2026-77117-2.patch: iconvdata: Test case for bug 34556,", " bug 34568 in iconvdata/Makefile, iconvdata/tst-jisx0213-progress.c.", " - CVE-2026-77117", " * SECURITY UPDATE: EUC_JISX0213 converter hang", " - debian/patches/CVE-2026-80489.patch: iconvdata: EUC_JISX0213 decoding", " lacks pending character reset (CVE-2026-80489) in iconvdata/euc-", " jisx0213.c.", " - CVE-2026-80489", "" ], "package": "glibc", "version": "2.39-0ubuntu8.9", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 03 Sep 2026 10:15:12 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libc6", "from_version": { "source_package_name": "glibc", "source_package_version": "2.39-0ubuntu8.8", "version": "2.39-0ubuntu8.8" }, "to_version": { "source_package_name": "glibc", "source_package_version": "2.39-0ubuntu8.9", "version": "2.39-0ubuntu8.9" }, "cves": [ { "cve": "CVE-2026-19499", "url": "https://ubuntu.com/security/CVE-2026-19499", "cve_description": "Calling strfmon and strfmon_l in the GNU C Library version 2.38 to 2.44 can write past the end of the caller-supplied output buffer when a conversion uses right-justified width padding. Exploitation requires an application code path that calls strfmon or strfmon_l with right-justified width padding into a destination buffer that is large enough for the padding to succeed but too small for the internal memmove call. The field width or format may be attacker-influenced or a fixed susceptible pattern in the caller. At the time of publication, no network-facing application impact is known.", "cve_priority": "medium", "cve_public_date": "2026-09-14 18:17:00 UTC" }, { "cve": "CVE-2026-19542", "url": "https://ubuntu.com/security/CVE-2026-19542", "cve_description": "Calling tdelete on a sufficiently deep tree in the GNU C Library version 2.1 to 2.44 may write one pointer past the end of an alloca-allocated array on the stack, which may crash the application. The tdelete implementation keeps an explicit stack of parent nodes for rebalancing, which is grown as needed while descending the tree. Two rebalancing branches push an additional entry without checking the capacity, and write past the array when the stack is exactly full. Triggering this requires a node at a depth of exactly 40 (or 40 plus a multiple of 20), which implies a tree with at least a million nodes, so an attacker must drive a large number of insertions and deletions through an application that uses tsearch and tdelete. The written value is a pointer into a tree node and is not directly attacker controlled. No affected application in common distributions has been identified.", "cve_priority": "medium", "cve_public_date": "2026-09-14 18:17:00 UTC" }, { "cve": "CVE-2026-6368", "url": "https://ubuntu.com/security/CVE-2026-6368", "cve_description": "Calling wordexp with WRDE_APPEND in the GNU C Library version 2.0 to version 2.43 can cause the interface to return invalid memory in the we_wordv member, which on subsequent calls to wordfree may abort the process.", "cve_priority": "medium", "cve_public_date": "2026-08-10 19:17:00 UTC" }, { "cve": "CVE-2026-6791", "url": "https://ubuntu.com/security/CVE-2026-6791", "cve_description": "When expanding paths that begin with a tilde (~) followed by a username, the internal parse_tilde function extracts the username to determine the user's home directory. The implementation allocates memory for this username directly on the stack using the strndupa macro. Because the size of this allocation was determined by the length of the user-supplied input without any bounds checks, passing an excessively long username e.g. thousands of characters, forces the thread to exhaust its stack space. Thus if an application passes untrusted, attacker-controlled input to the wordexp function, an attacker can trigger a stack clash.", "cve_priority": "medium", "cve_public_date": "2026-08-10 19:17:00 UTC" }, { "cve": "CVE-2026-77117", "url": "https://ubuntu.com/security/CVE-2026-77117", "cve_description": "Converting crafted SHIFT_JISX0213 input to UCS-4 or the internal wide character encoding, for example with iconv, in the GNU C Library version 2.3 to 2.44 may result in the converter making no progress, causing the calling application to hang. Some SHIFT_JISX0213 sequences decode to two code points. If the output buffer has room for only the first one, the converter stores the second in the conversion state and returns E2BIG, but it never clears that pending character after emitting it on the next call. The converter then keeps emitting the pending character without consuming further input, so an application that retries the conversion loops forever. The input must be attacker controlled and the application must convert it with an output buffer small enough to split the two code points. Only the SHIFT_JISX0213 character set is affected, which is not commonly used. The related defect in the EUC_JISX0213 converter is tracked separately as CVE-2026-80489.", "cve_priority": "medium", "cve_public_date": "2026-09-15 11:17:00 UTC" }, { "cve": "CVE-2026-80489", "url": "https://ubuntu.com/security/CVE-2026-80489", "cve_description": "Converting crafted EUC_JISX0213 input to UCS-4 or the internal wide character encoding, for example with iconv, in the GNU C Library version 2.3 to 2.44 may result in the converter making no progress, causing the calling application to hang. Some EUC_JISX0213 sequences decode to two code points. If the output buffer has room for only the first one, the converter stores the second in the conversion state and returns E2BIG, but it never clears that pending character after emitting it on the next call. The converter then keeps emitting the pending character without consuming further input, so an application that retries the conversion loops forever. The input must be attacker controlled and the application must convert it with an output buffer small enough to split the two code points. Only the EUC_JISX0213 character set is affected, which is not commonly used. The related defect in SHIFT_JISX0213 converter is tracked separately as CVE-2026-77117.", "cve_priority": "medium", "cve_public_date": "2026-09-15 11:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-19499", "url": "https://ubuntu.com/security/CVE-2026-19499", "cve_description": "Calling strfmon and strfmon_l in the GNU C Library version 2.38 to 2.44 can write past the end of the caller-supplied output buffer when a conversion uses right-justified width padding. Exploitation requires an application code path that calls strfmon or strfmon_l with right-justified width padding into a destination buffer that is large enough for the padding to succeed but too small for the internal memmove call. The field width or format may be attacker-influenced or a fixed susceptible pattern in the caller. At the time of publication, no network-facing application impact is known.", "cve_priority": "medium", "cve_public_date": "2026-09-14 18:17:00 UTC" }, { "cve": "CVE-2026-19542", "url": "https://ubuntu.com/security/CVE-2026-19542", "cve_description": "Calling tdelete on a sufficiently deep tree in the GNU C Library version 2.1 to 2.44 may write one pointer past the end of an alloca-allocated array on the stack, which may crash the application. The tdelete implementation keeps an explicit stack of parent nodes for rebalancing, which is grown as needed while descending the tree. Two rebalancing branches push an additional entry without checking the capacity, and write past the array when the stack is exactly full. Triggering this requires a node at a depth of exactly 40 (or 40 plus a multiple of 20), which implies a tree with at least a million nodes, so an attacker must drive a large number of insertions and deletions through an application that uses tsearch and tdelete. The written value is a pointer into a tree node and is not directly attacker controlled. No affected application in common distributions has been identified.", "cve_priority": "medium", "cve_public_date": "2026-09-14 18:17:00 UTC" }, { "cve": "CVE-2026-6368", "url": "https://ubuntu.com/security/CVE-2026-6368", "cve_description": "Calling wordexp with WRDE_APPEND in the GNU C Library version 2.0 to version 2.43 can cause the interface to return invalid memory in the we_wordv member, which on subsequent calls to wordfree may abort the process.", "cve_priority": "medium", "cve_public_date": "2026-08-10 19:17:00 UTC" }, { "cve": "CVE-2026-6791", "url": "https://ubuntu.com/security/CVE-2026-6791", "cve_description": "When expanding paths that begin with a tilde (~) followed by a username, the internal parse_tilde function extracts the username to determine the user's home directory. The implementation allocates memory for this username directly on the stack using the strndupa macro. Because the size of this allocation was determined by the length of the user-supplied input without any bounds checks, passing an excessively long username e.g. thousands of characters, forces the thread to exhaust its stack space. Thus if an application passes untrusted, attacker-controlled input to the wordexp function, an attacker can trigger a stack clash.", "cve_priority": "medium", "cve_public_date": "2026-08-10 19:17:00 UTC" }, { "cve": "CVE-2026-77117", "url": "https://ubuntu.com/security/CVE-2026-77117", "cve_description": "Converting crafted SHIFT_JISX0213 input to UCS-4 or the internal wide character encoding, for example with iconv, in the GNU C Library version 2.3 to 2.44 may result in the converter making no progress, causing the calling application to hang. Some SHIFT_JISX0213 sequences decode to two code points. If the output buffer has room for only the first one, the converter stores the second in the conversion state and returns E2BIG, but it never clears that pending character after emitting it on the next call. The converter then keeps emitting the pending character without consuming further input, so an application that retries the conversion loops forever. The input must be attacker controlled and the application must convert it with an output buffer small enough to split the two code points. Only the SHIFT_JISX0213 character set is affected, which is not commonly used. The related defect in the EUC_JISX0213 converter is tracked separately as CVE-2026-80489.", "cve_priority": "medium", "cve_public_date": "2026-09-15 11:17:00 UTC" }, { "cve": "CVE-2026-80489", "url": "https://ubuntu.com/security/CVE-2026-80489", "cve_description": "Converting crafted EUC_JISX0213 input to UCS-4 or the internal wide character encoding, for example with iconv, in the GNU C Library version 2.3 to 2.44 may result in the converter making no progress, causing the calling application to hang. Some EUC_JISX0213 sequences decode to two code points. If the output buffer has room for only the first one, the converter stores the second in the conversion state and returns E2BIG, but it never clears that pending character after emitting it on the next call. The converter then keeps emitting the pending character without consuming further input, so an application that retries the conversion loops forever. The input must be attacker controlled and the application must convert it with an output buffer small enough to split the two code points. Only the EUC_JISX0213 character set is affected, which is not commonly used. The related defect in SHIFT_JISX0213 converter is tracked separately as CVE-2026-77117.", "cve_priority": "medium", "cve_public_date": "2026-09-15 11:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer overflow in strfmon right-justification padding", " - debian/patches/CVE-2026-19499.patch: stdlib: Fix right-justification in", " strfmon (bug 34510, CVE-2026-19499) in stdlib/Makefile,", " stdlib/strfmon_l.c, stdlib/tst-strfmon-bug34510.c.", " - CVE-2026-19499", " * SECURITY UPDATE: Out-of-bounds stack array access in tdelete", " - debian/patches/CVE-2026-19542.patch: misc: Fix out-of-bounds array write", " in tdelete (bug 34506) in misc/tsearch.c.", " - CVE-2026-19542", " * SECURITY UPDATE: invalid memory when calling wordexp with WRDE_APPEND", " - debian/patches/CVE-2026-6368.patch: posix: Fix wordexp WRDE_APPEND to", " preserve state on non-NOSPACE errors (BZ 34090, CVE-2026-6368) in", " posix/Makefile, posix/tst-wordexp-append.c, posix/wordexp.c.", " - CVE-2026-6368", " * SECURITY UPDATE: stack clash issue when expanding long tilde paths", " - debian/patches/CVE-2026-6791.patch: posix: Fix stack overflow in wordexp", " tilde expansion (BZ 34091, CVE-2026-6791) in posix/Makefile, posix/tst-", " wordexp-tilde.c, posix/tst-wordexp-tilde.root/etc/group, posix/tst-", " wordexp-tilde.root/etc/nsswitch.conf, posix/tst-wordexp-", " tilde.root/etc/passwd, posix/wordexp.c.", " - CVE-2026-6791", " * SECURITY UPDATE: SHIFT_JISX0213 converter hang", " - debian/patches/CVE-2026-77117-1.patch: iconvdata: SHIFT_JISX0213 decoding", " lacks pending character reset (CVE-2026-77117) in", " iconvdata/shift_jisx0213.c.", " - debian/patches/CVE-2026-77117-2.patch: iconvdata: Test case for bug 34556,", " bug 34568 in iconvdata/Makefile, iconvdata/tst-jisx0213-progress.c.", " - CVE-2026-77117", " * SECURITY UPDATE: EUC_JISX0213 converter hang", " - debian/patches/CVE-2026-80489.patch: iconvdata: EUC_JISX0213 decoding", " lacks pending character reset (CVE-2026-80489) in iconvdata/euc-", " jisx0213.c.", " - CVE-2026-80489", "" ], "package": "glibc", "version": "2.39-0ubuntu8.9", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 03 Sep 2026 10:15:12 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libcurl4t64", "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", "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", "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", "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": "libk5crypto3", "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", "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", "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", "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": "libpython3.12-minimal", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.16", "version": "3.12.3-1ubuntu0.16" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.17", "version": "3.12.3-1ubuntu0.17" }, "cves": [ { "cve": "CVE-2026-4360", "url": "https://ubuntu.com/security/CVE-2026-4360", "cve_description": "In the Tarfile.extract() function, the filter parameter is not passed properly when extracting hardlinks. An affected system that extracts content from untrusted tar files could end up writing files with an unexpected uid/gid despite the user passing filter='data' to the extract() function.", "cve_priority": "medium", "cve_public_date": "2026-06-30 15:16:00 UTC" }, { "cve": "CVE-2026-15308", "url": "https://ubuntu.com/security/CVE-2026-15308", "cve_description": "The incremental HTML parser (html.parser.HTMLParser) allows for CPU denial-of-service through repeated unterminated markup declarations when processing uncontrolled data.", "cve_priority": "medium", "cve_public_date": "2026-07-09 17:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-4360", "url": "https://ubuntu.com/security/CVE-2026-4360", "cve_description": "In the Tarfile.extract() function, the filter parameter is not passed properly when extracting hardlinks. An affected system that extracts content from untrusted tar files could end up writing files with an unexpected uid/gid despite the user passing filter='data' to the extract() function.", "cve_priority": "medium", "cve_public_date": "2026-06-30 15:16:00 UTC" }, { "cve": "CVE-2026-15308", "url": "https://ubuntu.com/security/CVE-2026-15308", "cve_description": "The incremental HTML parser (html.parser.HTMLParser) allows for CPU denial-of-service through repeated unterminated markup declarations when processing uncontrolled data.", "cve_priority": "medium", "cve_public_date": "2026-07-09 17:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Incomplete filter application in tarfile extraction", " - debian/patches/CVE-2026-4360.patch: pass the filter function through", " extract() to target extraction in Lib/tarfile.py,", " Lib/test/test_tarfile.py.", " - CVE-2026-4360", " * SECURITY UPDATE: Quadratic complexity in incremental HTML parsing", " - debian/patches/CVE-2026-15308.patch: fix quadratic complexity in", " incremental parsing in HTMLParser in Lib/html/parser.py,", " Lib/test/test_htmlparser.py.", " - CVE-2026-15308", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.17", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Allen Huang ", "date": "Mon, 31 Aug 2026 11:18:26 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpython3.12-stdlib", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.16", "version": "3.12.3-1ubuntu0.16" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.17", "version": "3.12.3-1ubuntu0.17" }, "cves": [ { "cve": "CVE-2026-4360", "url": "https://ubuntu.com/security/CVE-2026-4360", "cve_description": "In the Tarfile.extract() function, the filter parameter is not passed properly when extracting hardlinks. An affected system that extracts content from untrusted tar files could end up writing files with an unexpected uid/gid despite the user passing filter='data' to the extract() function.", "cve_priority": "medium", "cve_public_date": "2026-06-30 15:16:00 UTC" }, { "cve": "CVE-2026-15308", "url": "https://ubuntu.com/security/CVE-2026-15308", "cve_description": "The incremental HTML parser (html.parser.HTMLParser) allows for CPU denial-of-service through repeated unterminated markup declarations when processing uncontrolled data.", "cve_priority": "medium", "cve_public_date": "2026-07-09 17:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-4360", "url": "https://ubuntu.com/security/CVE-2026-4360", "cve_description": "In the Tarfile.extract() function, the filter parameter is not passed properly when extracting hardlinks. An affected system that extracts content from untrusted tar files could end up writing files with an unexpected uid/gid despite the user passing filter='data' to the extract() function.", "cve_priority": "medium", "cve_public_date": "2026-06-30 15:16:00 UTC" }, { "cve": "CVE-2026-15308", "url": "https://ubuntu.com/security/CVE-2026-15308", "cve_description": "The incremental HTML parser (html.parser.HTMLParser) allows for CPU denial-of-service through repeated unterminated markup declarations when processing uncontrolled data.", "cve_priority": "medium", "cve_public_date": "2026-07-09 17:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Incomplete filter application in tarfile extraction", " - debian/patches/CVE-2026-4360.patch: pass the filter function through", " extract() to target extraction in Lib/tarfile.py,", " Lib/test/test_tarfile.py.", " - CVE-2026-4360", " * SECURITY UPDATE: Quadratic complexity in incremental HTML parsing", " - debian/patches/CVE-2026-15308.patch: fix quadratic complexity in", " incremental parsing in HTMLParser in Lib/html/parser.py,", " Lib/test/test_htmlparser.py.", " - CVE-2026-15308", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.17", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Allen Huang ", "date": "Mon, 31 Aug 2026 11:18:26 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "libsqlite3-0", "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": "libssl3t64", "from_version": { "source_package_name": "openssl", "source_package_version": "3.0.13-0ubuntu3.15", "version": "3.0.13-0ubuntu3.15" }, "to_version": { "source_package_name": "openssl", "source_package_version": "3.0.13-0ubuntu3.16", "version": "3.0.13-0ubuntu3.16" }, "cves": [ { "cve": "CVE-2026-35189", "url": "https://ubuntu.com/security/CVE-2026-35189", "cve_description": "Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54872", "url": "https://ubuntu.com/security/CVE-2026-54872", "cve_description": "Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature operations with curves that do not have a dedicated implementation leaks information about the secret nonce through timing. Impact summary: An attacker able to measure signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: The generic elliptic-curve scalar multiplication used for curves that do not have a dedicated constant-time implementation pads the secret scalar with non-constant-time BIGNUM operations, so the time taken depends on the value of the secret scalar derived from the ECDSA and SM2 nonce. The leak is very small; observing it requires a large number of measurements. The effect is largest for curves whose group order lies on a machine-word boundary, such as brainpoolP384r1. Applications using ECDSA signing over the Brainpool and other generic prime curves, and SM2 signing on platforms that use the generic implementation, are vulnerable to this issue. The NIST curves P-256, P-384 and P-521 use dedicated constant-time implementations and are not affected. FIPS Impact: no The FIPS modules are not affected: the approved NIST curves used in the FIPS provider have dedicated constant-time implementations and do not use the affected code path.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75805", "url": "https://ubuntu.com/security/CVE-2026-75805", "cve_description": "Issue summary: A CMP client that requests certificate revocation on the basis of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when processing a crafted revocation response. Impact summary: The NULL pointer dereference happens on a read which leads to a crash and a Denial of Service for the affected client application. CWE: CWE-476: NULL-pointer dereference Description: A CMP client revoking a certificate has to tell the server which certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the certificate itself or its issuer name and serial number. This is 'openssl cmp -cmd rr -csr ' on the command line, or OSSL_CMP_exec_RR_ses() with the certificate supplied via OSSL_CMP_CTX_set1_p10CSR() through the API. A CSR does not contain the issuer name and serial number of the certificate, so the client does not send them. A server may optionally name the certificate it revoked in its response, and the client then compares that name against what it sent. Having sent neither an issuer name nor a serial number, it has nothing to compare against, and a server returning a specially crafted name causes the client to read from a NULL pointer and crash. The revocation response is checked for valid message protection before the affected code is reached, so an attacker must be a malicious or compromised CMP server, or a man-in-the-middle in possession of the secret used for message protection. Clients that identify the certificate to be revoked by a certificate or by issuer and serial number rather than by a PKCS#10 CSR are not affected. FIPS impact: no No FIPS modules are affected by this issue, as the CMP protocol implementation is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75806", "url": "https://ubuntu.com/security/CVE-2026-75806", "cve_description": "Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-77696", "url": "https://ubuntu.com/security/CVE-2026-77696", "cve_description": "Issue summary: SM2 signature generation uses non-constant-time arithmetic on secret values, forming a timing side-channel. Impact summary: An attacker able to measure SM2 signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: SM2 signature generation computes the signature value using variable-time BIGNUM operations on the secret nonce and the private key, so the time taken to produce an SM2 signature depends on these secret values, forming a timing side-channel. Applications performing SM2 signature generation are affected on all platforms. FIPS Impact: no SM2 is not a FIPS algorithm.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84782", "url": "https://ubuntu.com/security/CVE-2026-84782", "cve_description": "Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "high", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-35189", "url": "https://ubuntu.com/security/CVE-2026-35189", "cve_description": "Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54872", "url": "https://ubuntu.com/security/CVE-2026-54872", "cve_description": "Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature operations with curves that do not have a dedicated implementation leaks information about the secret nonce through timing. Impact summary: An attacker able to measure signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: The generic elliptic-curve scalar multiplication used for curves that do not have a dedicated constant-time implementation pads the secret scalar with non-constant-time BIGNUM operations, so the time taken depends on the value of the secret scalar derived from the ECDSA and SM2 nonce. The leak is very small; observing it requires a large number of measurements. The effect is largest for curves whose group order lies on a machine-word boundary, such as brainpoolP384r1. Applications using ECDSA signing over the Brainpool and other generic prime curves, and SM2 signing on platforms that use the generic implementation, are vulnerable to this issue. The NIST curves P-256, P-384 and P-521 use dedicated constant-time implementations and are not affected. FIPS Impact: no The FIPS modules are not affected: the approved NIST curves used in the FIPS provider have dedicated constant-time implementations and do not use the affected code path.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75805", "url": "https://ubuntu.com/security/CVE-2026-75805", "cve_description": "Issue summary: A CMP client that requests certificate revocation on the basis of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when processing a crafted revocation response. Impact summary: The NULL pointer dereference happens on a read which leads to a crash and a Denial of Service for the affected client application. CWE: CWE-476: NULL-pointer dereference Description: A CMP client revoking a certificate has to tell the server which certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the certificate itself or its issuer name and serial number. This is 'openssl cmp -cmd rr -csr ' on the command line, or OSSL_CMP_exec_RR_ses() with the certificate supplied via OSSL_CMP_CTX_set1_p10CSR() through the API. A CSR does not contain the issuer name and serial number of the certificate, so the client does not send them. A server may optionally name the certificate it revoked in its response, and the client then compares that name against what it sent. Having sent neither an issuer name nor a serial number, it has nothing to compare against, and a server returning a specially crafted name causes the client to read from a NULL pointer and crash. The revocation response is checked for valid message protection before the affected code is reached, so an attacker must be a malicious or compromised CMP server, or a man-in-the-middle in possession of the secret used for message protection. Clients that identify the certificate to be revoked by a certificate or by issuer and serial number rather than by a PKCS#10 CSR are not affected. FIPS impact: no No FIPS modules are affected by this issue, as the CMP protocol implementation is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75806", "url": "https://ubuntu.com/security/CVE-2026-75806", "cve_description": "Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-77696", "url": "https://ubuntu.com/security/CVE-2026-77696", "cve_description": "Issue summary: SM2 signature generation uses non-constant-time arithmetic on secret values, forming a timing side-channel. Impact summary: An attacker able to measure SM2 signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: SM2 signature generation computes the signature value using variable-time BIGNUM operations on the secret nonce and the private key, so the time taken to produce an SM2 signature depends on these secret values, forming a timing side-channel. Applications performing SM2 signature generation are affected on all platforms. FIPS Impact: no SM2 is not a FIPS algorithm.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84782", "url": "https://ubuntu.com/security/CVE-2026-84782", "cve_description": "Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "high", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Excessive Memory Allocation in Relative CRLDP Processing", " - debian/patches/CVE-2026-35189.patch: Defer computation of relative CRLDP", " names in crypto/x509/v3_crld.c, crypto/x509/v3_purp.c,", " crypto/x509/x509_vfy.c, include/crypto/x509.h.", " - CVE-2026-35189", " * SECURITY UPDATE: Timing Side-Channel in Scalar Multiplication for Non-NIST", " EC Curves", " - debian/patches/CVE-2026-54872-pre1.patch: add value_barrier_bn() to", " include/internal/constant_time.h.", " - debian/patches/CVE-2026-54872.patch: ec: make ossl_ec_scalar_mul_ladder()", " scalar padding constant time in crypto/bn/bn_intern.c,", " crypto/ec/ec_mult.c, include/crypto/bn.h.", " - CVE-2026-54872", " * SECURITY UPDATE: NULL Pointer Dereference in CMP Client Revocation Response", " Handling", " - debian/patches/CVE-2026-75805-1.patch: Guard comparison when values are", " NULL in crypto/cmp/cmp_client.c.", " - debian/patches/CVE-2026-75805-2.patch: Add test for CVE-2026-75805 in", " test/cmp_client_test.c.", " - CVE-2026-75805", " * SECURITY UPDATE: Unauthenticated and Undersized DTLS 1.2 AEAD Record Causes", " DoS", " - debian/patches/CVE-2026-75806.patch: TLS: Reject undersized TLS 1.2 AEAD", " records before AEAD processing in ssl/record/record.h,", " ssl/record/ssl3_record.c, ssl/t1_enc.c, test/recordlentest.c.", " - CVE-2026-75806", " * SECURITY UPDATE: Timing Side-Channel in SM2 Signature Generation", " - debian/patches/CVE-2026-77696.patch: sm2: make sm2_sig_gen() constant time", " in crypto/ec/ec_mult.c, crypto/sm2/sm2_sign.c.", " - CVE-2026-77696", " * SECURITY UPDATE: DTLS Retransmits Handshake Messages From a Stale Buffer", " Offset", " - debian/patches/CVE-2026-84782.patch: dtls: reset init_off before", " retransmitting a message in ssl/d1_lib.c, ssl/statem/statem_dtls.c,", " test/dtlstest.c.", " - CVE-2026-84782", "" ], "package": "openssl", "version": "3.0.13-0ubuntu3.16", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 16 Sep 2026 14:47:02 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-139.139", "version": "6.8.0-139.139" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-146.146", "version": "6.8.0-146.146" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-146.146", "" ], "package": "linux-meta", "version": "6.8.0-146.146", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Edoardo Canepa ", "date": "Thu, 03 Sep 2026 17:48:49 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-145.145", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.8.0-145.145", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Tue, 01 Sep 2026 22:49:50 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-141.141", "" ], "package": "linux-meta", "version": "6.8.0-141.141", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Edoardo Canepa ", "date": "Sat, 29 Aug 2026 11:37:32 +0300" } ], "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": "openssl", "from_version": { "source_package_name": "openssl", "source_package_version": "3.0.13-0ubuntu3.15", "version": "3.0.13-0ubuntu3.15" }, "to_version": { "source_package_name": "openssl", "source_package_version": "3.0.13-0ubuntu3.16", "version": "3.0.13-0ubuntu3.16" }, "cves": [ { "cve": "CVE-2026-35189", "url": "https://ubuntu.com/security/CVE-2026-35189", "cve_description": "Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54872", "url": "https://ubuntu.com/security/CVE-2026-54872", "cve_description": "Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature operations with curves that do not have a dedicated implementation leaks information about the secret nonce through timing. Impact summary: An attacker able to measure signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: The generic elliptic-curve scalar multiplication used for curves that do not have a dedicated constant-time implementation pads the secret scalar with non-constant-time BIGNUM operations, so the time taken depends on the value of the secret scalar derived from the ECDSA and SM2 nonce. The leak is very small; observing it requires a large number of measurements. The effect is largest for curves whose group order lies on a machine-word boundary, such as brainpoolP384r1. Applications using ECDSA signing over the Brainpool and other generic prime curves, and SM2 signing on platforms that use the generic implementation, are vulnerable to this issue. The NIST curves P-256, P-384 and P-521 use dedicated constant-time implementations and are not affected. FIPS Impact: no The FIPS modules are not affected: the approved NIST curves used in the FIPS provider have dedicated constant-time implementations and do not use the affected code path.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75805", "url": "https://ubuntu.com/security/CVE-2026-75805", "cve_description": "Issue summary: A CMP client that requests certificate revocation on the basis of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when processing a crafted revocation response. Impact summary: The NULL pointer dereference happens on a read which leads to a crash and a Denial of Service for the affected client application. CWE: CWE-476: NULL-pointer dereference Description: A CMP client revoking a certificate has to tell the server which certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the certificate itself or its issuer name and serial number. This is 'openssl cmp -cmd rr -csr ' on the command line, or OSSL_CMP_exec_RR_ses() with the certificate supplied via OSSL_CMP_CTX_set1_p10CSR() through the API. A CSR does not contain the issuer name and serial number of the certificate, so the client does not send them. A server may optionally name the certificate it revoked in its response, and the client then compares that name against what it sent. Having sent neither an issuer name nor a serial number, it has nothing to compare against, and a server returning a specially crafted name causes the client to read from a NULL pointer and crash. The revocation response is checked for valid message protection before the affected code is reached, so an attacker must be a malicious or compromised CMP server, or a man-in-the-middle in possession of the secret used for message protection. Clients that identify the certificate to be revoked by a certificate or by issuer and serial number rather than by a PKCS#10 CSR are not affected. FIPS impact: no No FIPS modules are affected by this issue, as the CMP protocol implementation is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75806", "url": "https://ubuntu.com/security/CVE-2026-75806", "cve_description": "Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-77696", "url": "https://ubuntu.com/security/CVE-2026-77696", "cve_description": "Issue summary: SM2 signature generation uses non-constant-time arithmetic on secret values, forming a timing side-channel. Impact summary: An attacker able to measure SM2 signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: SM2 signature generation computes the signature value using variable-time BIGNUM operations on the secret nonce and the private key, so the time taken to produce an SM2 signature depends on these secret values, forming a timing side-channel. Applications performing SM2 signature generation are affected on all platforms. FIPS Impact: no SM2 is not a FIPS algorithm.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84782", "url": "https://ubuntu.com/security/CVE-2026-84782", "cve_description": "Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "high", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-35189", "url": "https://ubuntu.com/security/CVE-2026-35189", "cve_description": "Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54872", "url": "https://ubuntu.com/security/CVE-2026-54872", "cve_description": "Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature operations with curves that do not have a dedicated implementation leaks information about the secret nonce through timing. Impact summary: An attacker able to measure signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: The generic elliptic-curve scalar multiplication used for curves that do not have a dedicated constant-time implementation pads the secret scalar with non-constant-time BIGNUM operations, so the time taken depends on the value of the secret scalar derived from the ECDSA and SM2 nonce. The leak is very small; observing it requires a large number of measurements. The effect is largest for curves whose group order lies on a machine-word boundary, such as brainpoolP384r1. Applications using ECDSA signing over the Brainpool and other generic prime curves, and SM2 signing on platforms that use the generic implementation, are vulnerable to this issue. The NIST curves P-256, P-384 and P-521 use dedicated constant-time implementations and are not affected. FIPS Impact: no The FIPS modules are not affected: the approved NIST curves used in the FIPS provider have dedicated constant-time implementations and do not use the affected code path.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75805", "url": "https://ubuntu.com/security/CVE-2026-75805", "cve_description": "Issue summary: A CMP client that requests certificate revocation on the basis of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when processing a crafted revocation response. Impact summary: The NULL pointer dereference happens on a read which leads to a crash and a Denial of Service for the affected client application. CWE: CWE-476: NULL-pointer dereference Description: A CMP client revoking a certificate has to tell the server which certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the certificate itself or its issuer name and serial number. This is 'openssl cmp -cmd rr -csr ' on the command line, or OSSL_CMP_exec_RR_ses() with the certificate supplied via OSSL_CMP_CTX_set1_p10CSR() through the API. A CSR does not contain the issuer name and serial number of the certificate, so the client does not send them. A server may optionally name the certificate it revoked in its response, and the client then compares that name against what it sent. Having sent neither an issuer name nor a serial number, it has nothing to compare against, and a server returning a specially crafted name causes the client to read from a NULL pointer and crash. The revocation response is checked for valid message protection before the affected code is reached, so an attacker must be a malicious or compromised CMP server, or a man-in-the-middle in possession of the secret used for message protection. Clients that identify the certificate to be revoked by a certificate or by issuer and serial number rather than by a PKCS#10 CSR are not affected. FIPS impact: no No FIPS modules are affected by this issue, as the CMP protocol implementation is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75806", "url": "https://ubuntu.com/security/CVE-2026-75806", "cve_description": "Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-77696", "url": "https://ubuntu.com/security/CVE-2026-77696", "cve_description": "Issue summary: SM2 signature generation uses non-constant-time arithmetic on secret values, forming a timing side-channel. Impact summary: An attacker able to measure SM2 signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: SM2 signature generation computes the signature value using variable-time BIGNUM operations on the secret nonce and the private key, so the time taken to produce an SM2 signature depends on these secret values, forming a timing side-channel. Applications performing SM2 signature generation are affected on all platforms. FIPS Impact: no SM2 is not a FIPS algorithm.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84782", "url": "https://ubuntu.com/security/CVE-2026-84782", "cve_description": "Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "high", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Excessive Memory Allocation in Relative CRLDP Processing", " - debian/patches/CVE-2026-35189.patch: Defer computation of relative CRLDP", " names in crypto/x509/v3_crld.c, crypto/x509/v3_purp.c,", " crypto/x509/x509_vfy.c, include/crypto/x509.h.", " - CVE-2026-35189", " * SECURITY UPDATE: Timing Side-Channel in Scalar Multiplication for Non-NIST", " EC Curves", " - debian/patches/CVE-2026-54872-pre1.patch: add value_barrier_bn() to", " include/internal/constant_time.h.", " - debian/patches/CVE-2026-54872.patch: ec: make ossl_ec_scalar_mul_ladder()", " scalar padding constant time in crypto/bn/bn_intern.c,", " crypto/ec/ec_mult.c, include/crypto/bn.h.", " - CVE-2026-54872", " * SECURITY UPDATE: NULL Pointer Dereference in CMP Client Revocation Response", " Handling", " - debian/patches/CVE-2026-75805-1.patch: Guard comparison when values are", " NULL in crypto/cmp/cmp_client.c.", " - debian/patches/CVE-2026-75805-2.patch: Add test for CVE-2026-75805 in", " test/cmp_client_test.c.", " - CVE-2026-75805", " * SECURITY UPDATE: Unauthenticated and Undersized DTLS 1.2 AEAD Record Causes", " DoS", " - debian/patches/CVE-2026-75806.patch: TLS: Reject undersized TLS 1.2 AEAD", " records before AEAD processing in ssl/record/record.h,", " ssl/record/ssl3_record.c, ssl/t1_enc.c, test/recordlentest.c.", " - CVE-2026-75806", " * SECURITY UPDATE: Timing Side-Channel in SM2 Signature Generation", " - debian/patches/CVE-2026-77696.patch: sm2: make sm2_sig_gen() constant time", " in crypto/ec/ec_mult.c, crypto/sm2/sm2_sign.c.", " - CVE-2026-77696", " * SECURITY UPDATE: DTLS Retransmits Handshake Messages From a Stale Buffer", " Offset", " - debian/patches/CVE-2026-84782.patch: dtls: reset init_off before", " retransmitting a message in ssl/d1_lib.c, ssl/statem/statem_dtls.c,", " test/dtlstest.c.", " - CVE-2026-84782", "" ], "package": "openssl", "version": "3.0.13-0ubuntu3.16", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 16 Sep 2026 14:47:02 -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": "python-apt-common", "from_version": { "source_package_name": "python-apt", "source_package_version": "2.7.7ubuntu5.2", "version": "2.7.7ubuntu5.2" }, "to_version": { "source_package_name": "python-apt", "source_package_version": "2.7.7ubuntu5.3", "version": "2.7.7ubuntu5.3" }, "cves": [], "launchpad_bugs_fixed": [ 2166601 ], "changes": [ { "cves": [], "log": [ "", " * Mirror list update for 24.04.5 (LP: #2166601)", "" ], "package": "python-apt", "version": "2.7.7ubuntu5.3", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2166601 ], "author": "Graham Inggs ", "date": "Sun, 06 Sep 2026 14:01:38 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-apt", "from_version": { "source_package_name": "python-apt", "source_package_version": "2.7.7ubuntu5.2", "version": "2.7.7ubuntu5.2" }, "to_version": { "source_package_name": "python-apt", "source_package_version": "2.7.7ubuntu5.3", "version": "2.7.7ubuntu5.3" }, "cves": [], "launchpad_bugs_fixed": [ 2166601 ], "changes": [ { "cves": [], "log": [ "", " * Mirror list update for 24.04.5 (LP: #2166601)", "" ], "package": "python-apt", "version": "2.7.7ubuntu5.3", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2166601 ], "author": "Graham Inggs ", "date": "Sun, 06 Sep 2026 14:01:38 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-distupgrade", "from_version": { "source_package_name": "ubuntu-release-upgrader", "source_package_version": "1:24.04.28", "version": "1:24.04.28" }, "to_version": { "source_package_name": "ubuntu-release-upgrader", "source_package_version": "1:24.04.29", "version": "1:24.04.29" }, "cves": [], "launchpad_bugs_fixed": [ 2078579, 2166415 ], "changes": [ { "cves": [], "log": [ "", " * Install dependencies of t64 packages (LP: #2078579)", " * Run pre-build.sh: updating mirrors (and .po offsets) for point release.", " (LP: #2166415)", "" ], "package": "ubuntu-release-upgrader", "version": "1:24.04.29", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2078579, 2166415 ], "author": "Julian Andres Klode ", "date": "Thu, 03 Sep 2026 23:11:07 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-jwt", "from_version": { "source_package_name": "pyjwt", "source_package_version": "2.7.0-1ubuntu0.1", "version": "2.7.0-1ubuntu0.1" }, "to_version": { "source_package_name": "pyjwt", "source_package_version": "2.7.0-1ubuntu0.2", "version": "2.7.0-1ubuntu0.2" }, "cves": [ { "cve": "CVE-2026-48522", "url": "https://ubuntu.com/security/CVE-2026-48522", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch. If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem), cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface), or forge tokens that PyJWT verifies as valid. The library does not directly return non-HTTP(S) URI contents to the attacker; the chained \"plant a JWKS to forge tokens\" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48524", "url": "https://ubuntu.com/security/CVE-2026-48524", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient.get_signing_key() forces a fresh HTTP request to the JWKS endpoint for every JWT with an unknown kid value, with no rate limiting. Since kid comes from the unverified token header, an attacker can trigger unlimited outbound requests. The vulnerability surfaces only when a JWKS fetch fails; an attacker can attempt to provoke that with sustained unknown-kid traffic, but the outcome depends on upstream JWKS-endpoint behavior (rate limiting, transient errors) which is beyond the attacker's control. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48525", "url": "https://ubuntu.com/security/CVE-2026-48525", "cve_description": "PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option (\"b64\": false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48526", "url": "https://ubuntu.com/security/CVE-2026-48526", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-48522", "url": "https://ubuntu.com/security/CVE-2026-48522", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch. If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem), cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface), or forge tokens that PyJWT verifies as valid. The library does not directly return non-HTTP(S) URI contents to the attacker; the chained \"plant a JWKS to forge tokens\" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48524", "url": "https://ubuntu.com/security/CVE-2026-48524", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient.get_signing_key() forces a fresh HTTP request to the JWKS endpoint for every JWT with an unknown kid value, with no rate limiting. Since kid comes from the unverified token header, an attacker can trigger unlimited outbound requests. The vulnerability surfaces only when a JWKS fetch fails; an attacker can attempt to provoke that with sustained unknown-kid traffic, but the outcome depends on upstream JWKS-endpoint behavior (rate limiting, transient errors) which is beyond the attacker's control. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48525", "url": "https://ubuntu.com/security/CVE-2026-48525", "cve_description": "PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option (\"b64\": false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48526", "url": "https://ubuntu.com/security/CVE-2026-48526", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: multiple security vulnerabilities", " - debian/patches/CVE-2026-48522-to-48526.patch: Bundle security fixes and", " hardening into 2.13.0 in jwt/algorithms.py, jwt/api_jws.py,", " jwt/jwks_client.py, tests/test_algorithms.py, tests/test_api_jws.py,", " tests/test_jwks_client.py.", " - CVE-2026-48522", " - CVE-2026-48524", " - CVE-2026-48525", " - CVE-2026-48526", "" ], "package": "pyjwt", "version": "2.7.0-1ubuntu0.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Shishir Subedi ", "date": "Mon, 21 Sep 2026 13:39:20 +0545" } ], "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": "python3-requests", "from_version": { "source_package_name": "requests", "source_package_version": "2.31.0+dfsg-1ubuntu1.1", "version": "2.31.0+dfsg-1ubuntu1.1" }, "to_version": { "source_package_name": "requests", "source_package_version": "2.31.0+dfsg-1ubuntu1.2", "version": "2.31.0+dfsg-1ubuntu1.2" }, "cves": [ { "cve": "CVE-2026-25645", "url": "https://ubuntu.com/security/CVE-2026-25645", "cve_description": "Requests is a HTTP library. Prior to version 2.33.0, the `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Standard usage of the Requests library is not affected by this vulnerability. Only applications that call `extract_zipped_paths()` directly are impacted. Starting in version 2.33.0, the library extracts files to a non-deterministic location. If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.", "cve_priority": "low", "cve_public_date": "2026-03-25 17:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-25645", "url": "https://ubuntu.com/security/CVE-2026-25645", "cve_description": "Requests is a HTTP library. Prior to version 2.33.0, the `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Standard usage of the Requests library is not affected by this vulnerability. Only applications that call `extract_zipped_paths()` directly are impacted. Starting in version 2.33.0, the library extracts files to a non-deterministic location. If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.", "cve_priority": "low", "cve_public_date": "2026-03-25 17:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Insecure Temporary File", " - debian/patches/CVE-2026-25645.patch: Extract to non-deterministic", " location", " - CVE-2026-25645", "" ], "package": "requests", "version": "2.31.0+dfsg-1ubuntu1.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Wed, 23 Sep 2026 13:12:59 +1000" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3.12", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.16", "version": "3.12.3-1ubuntu0.16" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.17", "version": "3.12.3-1ubuntu0.17" }, "cves": [ { "cve": "CVE-2026-4360", "url": "https://ubuntu.com/security/CVE-2026-4360", "cve_description": "In the Tarfile.extract() function, the filter parameter is not passed properly when extracting hardlinks. An affected system that extracts content from untrusted tar files could end up writing files with an unexpected uid/gid despite the user passing filter='data' to the extract() function.", "cve_priority": "medium", "cve_public_date": "2026-06-30 15:16:00 UTC" }, { "cve": "CVE-2026-15308", "url": "https://ubuntu.com/security/CVE-2026-15308", "cve_description": "The incremental HTML parser (html.parser.HTMLParser) allows for CPU denial-of-service through repeated unterminated markup declarations when processing uncontrolled data.", "cve_priority": "medium", "cve_public_date": "2026-07-09 17:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-4360", "url": "https://ubuntu.com/security/CVE-2026-4360", "cve_description": "In the Tarfile.extract() function, the filter parameter is not passed properly when extracting hardlinks. An affected system that extracts content from untrusted tar files could end up writing files with an unexpected uid/gid despite the user passing filter='data' to the extract() function.", "cve_priority": "medium", "cve_public_date": "2026-06-30 15:16:00 UTC" }, { "cve": "CVE-2026-15308", "url": "https://ubuntu.com/security/CVE-2026-15308", "cve_description": "The incremental HTML parser (html.parser.HTMLParser) allows for CPU denial-of-service through repeated unterminated markup declarations when processing uncontrolled data.", "cve_priority": "medium", "cve_public_date": "2026-07-09 17:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Incomplete filter application in tarfile extraction", " - debian/patches/CVE-2026-4360.patch: pass the filter function through", " extract() to target extraction in Lib/tarfile.py,", " Lib/test/test_tarfile.py.", " - CVE-2026-4360", " * SECURITY UPDATE: Quadratic complexity in incremental HTML parsing", " - debian/patches/CVE-2026-15308.patch: fix quadratic complexity in", " incremental parsing in HTMLParser in Lib/html/parser.py,", " Lib/test/test_htmlparser.py.", " - CVE-2026-15308", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.17", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Allen Huang ", "date": "Mon, 31 Aug 2026 11:18:26 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3.12-minimal", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.16", "version": "3.12.3-1ubuntu0.16" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.17", "version": "3.12.3-1ubuntu0.17" }, "cves": [ { "cve": "CVE-2026-4360", "url": "https://ubuntu.com/security/CVE-2026-4360", "cve_description": "In the Tarfile.extract() function, the filter parameter is not passed properly when extracting hardlinks. An affected system that extracts content from untrusted tar files could end up writing files with an unexpected uid/gid despite the user passing filter='data' to the extract() function.", "cve_priority": "medium", "cve_public_date": "2026-06-30 15:16:00 UTC" }, { "cve": "CVE-2026-15308", "url": "https://ubuntu.com/security/CVE-2026-15308", "cve_description": "The incremental HTML parser (html.parser.HTMLParser) allows for CPU denial-of-service through repeated unterminated markup declarations when processing uncontrolled data.", "cve_priority": "medium", "cve_public_date": "2026-07-09 17:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-4360", "url": "https://ubuntu.com/security/CVE-2026-4360", "cve_description": "In the Tarfile.extract() function, the filter parameter is not passed properly when extracting hardlinks. An affected system that extracts content from untrusted tar files could end up writing files with an unexpected uid/gid despite the user passing filter='data' to the extract() function.", "cve_priority": "medium", "cve_public_date": "2026-06-30 15:16:00 UTC" }, { "cve": "CVE-2026-15308", "url": "https://ubuntu.com/security/CVE-2026-15308", "cve_description": "The incremental HTML parser (html.parser.HTMLParser) allows for CPU denial-of-service through repeated unterminated markup declarations when processing uncontrolled data.", "cve_priority": "medium", "cve_public_date": "2026-07-09 17:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Incomplete filter application in tarfile extraction", " - debian/patches/CVE-2026-4360.patch: pass the filter function through", " extract() to target extraction in Lib/tarfile.py,", " Lib/test/test_tarfile.py.", " - CVE-2026-4360", " * SECURITY UPDATE: Quadratic complexity in incremental HTML parsing", " - debian/patches/CVE-2026-15308.patch: fix quadratic complexity in", " incremental parsing in HTMLParser in Lib/html/parser.py,", " Lib/test/test_htmlparser.py.", " - CVE-2026-15308", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.17", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Allen Huang ", "date": "Mon, 31 Aug 2026 11:18:26 +0100" } ], "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 }, { "name": "ubuntu-release-upgrader-core", "from_version": { "source_package_name": "ubuntu-release-upgrader", "source_package_version": "1:24.04.28", "version": "1:24.04.28" }, "to_version": { "source_package_name": "ubuntu-release-upgrader", "source_package_version": "1:24.04.29", "version": "1:24.04.29" }, "cves": [], "launchpad_bugs_fixed": [ 2078579, 2166415 ], "changes": [ { "cves": [], "log": [ "", " * Install dependencies of t64 packages (LP: #2078579)", " * Run pre-build.sh: updating mirrors (and .po offsets) for point release.", " (LP: #2166415)", "" ], "package": "ubuntu-release-upgrader", "version": "1:24.04.29", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2078579, 2166415 ], "author": "Julian Andres Klode ", "date": "Thu, 03 Sep 2026 23:11:07 +0200" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-image-6.8.0-146-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-139.139", "version": null }, "to_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-146.146", "version": "6.8.0-146.146" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 1786013, 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-146.146", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-146.146", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Thu, 03 Sep 2026 17:49:07 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-145.145", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-145.145", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Tue, 01 Sep 2026 22:50:01 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-141.141", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-141.141", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Sat, 29 Aug 2026 11:37:53 +0300" } ], "notes": "linux-image-6.8.0-146-generic version '6.8.0-146.146' (source package linux-signed version '6.8.0-146.146') was added. linux-image-6.8.0-146-generic version '6.8.0-146.146' has the same source package name, linux-signed, as removed package linux-image-6.8.0-139-generic. As such we can use the source package version of the removed package, '6.8.0-139.139', 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-6.8.0-146-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-139.139", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-146.146", "version": "6.8.0-146.146" }, "cves": [ { "cve": "CVE-2026-53132", "url": "https://ubuntu.com/security/CVE-2026-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: \t(Number of skbs in the queue) * SKB_TRUESIZE(0)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53140", "url": "https://ubuntu.com/security/CVE-2026-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53156", "url": "https://ubuntu.com/security/CVE-2026-53156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53202", "url": "https://ubuntu.com/security/CVE-2026-53202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53205", "url": "https://ubuntu.com/security/CVE-2026-53205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53210", "url": "https://ubuntu.com/security/CVE-2026-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-31663", "url": "https://ubuntu.com/security/CVE-2026-31663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-53220", "url": "https://ubuntu.com/security/CVE-2026-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53229", "url": "https://ubuntu.com/security/CVE-2026-53229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46203", "url": "https://ubuntu.com/security/CVE-2026-46203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: fix unclocked access on unbind Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-63871", "url": "https://ubuntu.com/security/CVE-2026-63871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53251", "url": "https://ubuntu.com/security/CVE-2026-53251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63869", "url": "https://ubuntu.com/security/CVE-2026-63869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: \tinfo->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53261", "url": "https://ubuntu.com/security/CVE-2026-53261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53262", "url": "https://ubuntu.com/security/CVE-2026-53262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "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-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52908", "url": "https://ubuntu.com/security/CVE-2026-52908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63883", "url": "https://ubuntu.com/security/CVE-2026-63883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64528", "url": "https://ubuntu.com/security/CVE-2026-64528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53329", "url": "https://ubuntu.com/security/CVE-2026-53329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as \"capacity * vector->struct_size\" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53143", "url": "https://ubuntu.com/security/CVE-2026-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53144", "url": "https://ubuntu.com/security/CVE-2026-53144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53331", "url": "https://ubuntu.com/security/CVE-2026-53331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53147", "url": "https://ubuntu.com/security/CVE-2026-53147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53154", "url": "https://ubuntu.com/security/CVE-2026-53154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c (\"mm: hwpoison: support recovery from HugePage copy-on-write faults\") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53336", "url": "https://ubuntu.com/security/CVE-2026-53336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53337", "url": "https://ubuntu.com/security/CVE-2026-53337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, \"slave_dev=%p:\\n\", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, \"(slave %s): \" fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53160", "url": "https://ubuntu.com/security/CVE-2026-53160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53339", "url": "https://ubuntu.com/security/CVE-2026-53339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53182", "url": "https://ubuntu.com/security/CVE-2026-53182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53183", "url": "https://ubuntu.com/security/CVE-2026-53183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63867", "url": "https://ubuntu.com/security/CVE-2026-63867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close TOCTOU race while computing rcv_wnd The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53343", "url": "https://ubuntu.com/security/CVE-2026-53343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 (\"ARM: 9430/1: entry: Do a dummy read from VMAP shadow\") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53184", "url": "https://ubuntu.com/security/CVE-2026-53184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: \tif (skb->dev) \t\tcaller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53185", "url": "https://ubuntu.com/security/CVE-2026-53185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d (\"zram: fix synchronous reads\") for the same reason; the write_partial counterpart was missed.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53190", "url": "https://ubuntu.com/security/CVE-2026-53190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53198", "url": "https://ubuntu.com/security/CVE-2026-53198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which \"goto out\"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53356", "url": "https://ubuntu.com/security/CVE-2026-53356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)", "cve_priority": "high", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53345", "url": "https://ubuntu.com/security/CVE-2026-53345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically \"misses\" a push to the dirty ring is irrelevant.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53209", "url": "https://ubuntu.com/security/CVE-2026-53209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53347", "url": "https://ubuntu.com/security/CVE-2026-53347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-43116", "url": "https://ubuntu.com/security/CVE-2026-43116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-53214", "url": "https://ubuntu.com/security/CVE-2026-53214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid possible NULL deref in modify_prefix_route()\"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53349", "url": "https://ubuntu.com/security/CVE-2026-53349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53230", "url": "https://ubuntu.com/security/CVE-2026-53230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53232", "url": "https://ubuntu.com/security/CVE-2026-53232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53236", "url": "https://ubuntu.com/security/CVE-2026-53236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53350", "url": "https://ubuntu.com/security/CVE-2026-53350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53237", "url": "https://ubuntu.com/security/CVE-2026-53237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-53242", "url": "https://ubuntu.com/security/CVE-2026-53242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53352", "url": "https://ubuntu.com/security/CVE-2026-53352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63870", "url": "https://ubuntu.com/security/CVE-2026-63870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63868", "url": "https://ubuntu.com/security/CVE-2026-63868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53353", "url": "https://ubuntu.com/security/CVE-2026-53353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 ", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53267", "url": "https://ubuntu.com/security/CVE-2026-53267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53274", "url": "https://ubuntu.com/security/CVE-2026-53274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-63898", "url": "https://ubuntu.com/security/CVE-2026-63898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-43311", "url": "https://ubuntu.com/security/CVE-2026-43311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix unsafe generic_handle_irq() call Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. [treding@nvidia.com: miscellaneous cleanups]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43240", "url": "https://ubuntu.com/security/CVE-2026-43240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: add a sanity check on previous kernel's ima kexec buffer When the second-stage kernel is booted via kexec with a limiting command line such as \"mem=\", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b (\"of: check previous kernel's ima-kexec-buffer against memory bounds\") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23346", "url": "https://ubuntu.com/security/CVE-2026-23346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-64006", "url": "https://ubuntu.com/security/CVE-2026-64006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-43331", "url": "https://ubuntu.com/security/CVE-2026-43331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-53358", "url": "https://ubuntu.com/security/CVE-2026-53358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.", "cve_priority": "medium", "cve_public_date": "2026-07-02 15:17:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-68768", "url": "https://ubuntu.com/security/CVE-2025-68768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:15:00 UTC" }, { "cve": "CVE-2026-43303", "url": "https://ubuntu.com/security/CVE-2026-43303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17: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": [ 2166353, 1786013, 2165873, 2164507, 2163508, 2161004, 2089306, 2164716, 2164516, 2132119, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547 ], "changes": [ { "cves": [ { "cve": "CVE-2026-53132", "url": "https://ubuntu.com/security/CVE-2026-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: \t(Number of skbs in the queue) * SKB_TRUESIZE(0)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53140", "url": "https://ubuntu.com/security/CVE-2026-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53156", "url": "https://ubuntu.com/security/CVE-2026-53156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53202", "url": "https://ubuntu.com/security/CVE-2026-53202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53205", "url": "https://ubuntu.com/security/CVE-2026-53205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53210", "url": "https://ubuntu.com/security/CVE-2026-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-31663", "url": "https://ubuntu.com/security/CVE-2026-31663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-53220", "url": "https://ubuntu.com/security/CVE-2026-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53229", "url": "https://ubuntu.com/security/CVE-2026-53229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46203", "url": "https://ubuntu.com/security/CVE-2026-46203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: fix unclocked access on unbind Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-63871", "url": "https://ubuntu.com/security/CVE-2026-63871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53251", "url": "https://ubuntu.com/security/CVE-2026-53251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63869", "url": "https://ubuntu.com/security/CVE-2026-63869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: \tinfo->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53261", "url": "https://ubuntu.com/security/CVE-2026-53261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53262", "url": "https://ubuntu.com/security/CVE-2026-53262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "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-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52908", "url": "https://ubuntu.com/security/CVE-2026-52908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63883", "url": "https://ubuntu.com/security/CVE-2026-63883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64528", "url": "https://ubuntu.com/security/CVE-2026-64528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53329", "url": "https://ubuntu.com/security/CVE-2026-53329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as \"capacity * vector->struct_size\" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53143", "url": "https://ubuntu.com/security/CVE-2026-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53144", "url": "https://ubuntu.com/security/CVE-2026-53144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53331", "url": "https://ubuntu.com/security/CVE-2026-53331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53147", "url": "https://ubuntu.com/security/CVE-2026-53147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53154", "url": "https://ubuntu.com/security/CVE-2026-53154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c (\"mm: hwpoison: support recovery from HugePage copy-on-write faults\") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53336", "url": "https://ubuntu.com/security/CVE-2026-53336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53337", "url": "https://ubuntu.com/security/CVE-2026-53337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, \"slave_dev=%p:\\n\", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, \"(slave %s): \" fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53160", "url": "https://ubuntu.com/security/CVE-2026-53160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53339", "url": "https://ubuntu.com/security/CVE-2026-53339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53182", "url": "https://ubuntu.com/security/CVE-2026-53182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53183", "url": "https://ubuntu.com/security/CVE-2026-53183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63867", "url": "https://ubuntu.com/security/CVE-2026-63867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close TOCTOU race while computing rcv_wnd The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53343", "url": "https://ubuntu.com/security/CVE-2026-53343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 (\"ARM: 9430/1: entry: Do a dummy read from VMAP shadow\") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53184", "url": "https://ubuntu.com/security/CVE-2026-53184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: \tif (skb->dev) \t\tcaller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53185", "url": "https://ubuntu.com/security/CVE-2026-53185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d (\"zram: fix synchronous reads\") for the same reason; the write_partial counterpart was missed.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53190", "url": "https://ubuntu.com/security/CVE-2026-53190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53198", "url": "https://ubuntu.com/security/CVE-2026-53198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which \"goto out\"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53356", "url": "https://ubuntu.com/security/CVE-2026-53356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)", "cve_priority": "high", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53345", "url": "https://ubuntu.com/security/CVE-2026-53345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically \"misses\" a push to the dirty ring is irrelevant.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53209", "url": "https://ubuntu.com/security/CVE-2026-53209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53347", "url": "https://ubuntu.com/security/CVE-2026-53347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-43116", "url": "https://ubuntu.com/security/CVE-2026-43116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-53214", "url": "https://ubuntu.com/security/CVE-2026-53214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid possible NULL deref in modify_prefix_route()\"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53349", "url": "https://ubuntu.com/security/CVE-2026-53349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53230", "url": "https://ubuntu.com/security/CVE-2026-53230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53232", "url": "https://ubuntu.com/security/CVE-2026-53232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53236", "url": "https://ubuntu.com/security/CVE-2026-53236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53350", "url": "https://ubuntu.com/security/CVE-2026-53350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53237", "url": "https://ubuntu.com/security/CVE-2026-53237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-53242", "url": "https://ubuntu.com/security/CVE-2026-53242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53352", "url": "https://ubuntu.com/security/CVE-2026-53352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63870", "url": "https://ubuntu.com/security/CVE-2026-63870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63868", "url": "https://ubuntu.com/security/CVE-2026-63868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53353", "url": "https://ubuntu.com/security/CVE-2026-53353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 ", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53267", "url": "https://ubuntu.com/security/CVE-2026-53267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53274", "url": "https://ubuntu.com/security/CVE-2026-53274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-63898", "url": "https://ubuntu.com/security/CVE-2026-63898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-43311", "url": "https://ubuntu.com/security/CVE-2026-43311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix unsafe generic_handle_irq() call Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. [treding@nvidia.com: miscellaneous cleanups]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43240", "url": "https://ubuntu.com/security/CVE-2026-43240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: add a sanity check on previous kernel's ima kexec buffer When the second-stage kernel is booted via kexec with a limiting command line such as \"mem=\", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b (\"of: check previous kernel's ima-kexec-buffer against memory bounds\") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23346", "url": "https://ubuntu.com/security/CVE-2026-23346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-64006", "url": "https://ubuntu.com/security/CVE-2026-64006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-43331", "url": "https://ubuntu.com/security/CVE-2026-43331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-53358", "url": "https://ubuntu.com/security/CVE-2026-53358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.", "cve_priority": "medium", "cve_public_date": "2026-07-02 15:17:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-68768", "url": "https://ubuntu.com/security/CVE-2025-68768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:15:00 UTC" }, { "cve": "CVE-2026-43303", "url": "https://ubuntu.com/security/CVE-2026-43303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17: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-146.146 -proposed tracker (LP: #2166353)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.08.31)", "", " * Bluetooth fails to initialize due to a kernel NULL pointer error", " (LP: #2165873)", " - Bluetooth: btmtk: move btusb_mtk_[setup, shutdown] to btmtk.c", "", " * Dell Precision fails to shutdown when HDMI display is connected (22.04", " HWE) (LP: #2164507)", " - drm/i915/vbt: Add fields dedicated_external and dyn_port_over_tc", " - drm/i915/display: Handle dedicated external ports in", " intel_encoder_is_tc()", "", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", "", " * [SRU] HPE: Fix for UBSAN array-index-out-of-bounds (LP: #2161004)", " - x86/platform/uv: Fix UBSAN array-index-out-of-bounds", "", " * vfio_pci soft lockup on VM start while using PCIe passthrough", " (LP: #2089306)", " - SAUCE: Revert \"vfio/pci: Use unmap_mapping_range()\"", "", " * Reboot machine with ext4 configured to data=journal could dump spurious", " call trace (LP: #2164716)", " - ext4: clear stale xarray tags on folios skipped during writeback", "", " * [UBUNTU 22.04] s390/topology: Use zero-based numbering (LP: #2164516)", " - s390/topology: Use zero-based numbering for containing entities", "", " * [HP][ZBook Power 16 G11] Laptop freezed after upgrading the BIOS", " (LP: #2132119)", " - PCI/ASPM: Avoid L0s for Realtek RTS525A", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796)", " - netfilter: bitwise: rename some boolean operation functions", " - netfilter: bitwise: add support for doing AND, OR and XOR directly", " - drm/fbdev-helper: Set and clear VGA switcheroo client from fb_info", " - arm64: io: Rename ioremap_prot() to __ioremap_prot()", " - Disable -Wattribute-alias for clang-23 and newer", " - netfilter: xt_NFQUEUE: prefer raw_smp_processor_id", " - drm/imx: Fix three kernel-doc warnings in dcss-scaler.c", " - pcnet32: stop holding device spin lock during napi_complete_done", " - net: Annotate sk->sk_write_space() for UDP SOCKMAP.", " - net: lan743x: permit VLAN-tagged packets up to configured MTU", " - net: fec: fix pinctrl default state restore order on resume", " - Bluetooth: bnep: fix incorrect length parsing in bnep_rx_frame()", " extension handling", " - Bluetooth: MGMT: Fix backward compatibility with userspace", " - ptp: vclock: Switch from RCU to SRCU", " - octeontx2-af: npc: Fix CPT channel mask in npc_install_flow", " - vxlan: vnifilter: send notification on VNI add", " - vxlan: vnifilter: fix spurious notification on VNI update", " - ipmi: Fix rcu_read_unlock to srcu_read_unlock in handle_read_event_rsp", " - time: Fix off-by-one in settimeofday() usec validation", " - tools/rv: Fix cleanup after failed trace setup", " - arm64: tlb: Allow XZR argument to TLBI ops", " - iomap: don't revert iov_iter on partially completed buffered writes", " - net/mlx4: avoid GCC 10 __bad_copy_from() false positive", " - r8152: handle the return value of usb_reset_device()", " - rds: mark snapshot pages dirty in rds_info_getsockopt()", " - net: mvpp2: Add metadata support for xdp mode", " - net: mvpp2: build skb from XDP-adjusted data on XDP_PASS", " - clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time", " - tracing/probes: Point the error offset correctly for eprobe argument", " error", " - mmc: litex_mmc: Use DIV_ROUND_UP for more accurate clock calculation", " - USB: serial: option: add usb-id for Dell Wireless DW5826e-m", " - ALSA: timer: Fix UAF at snd_timer_user_params()", " - drm/amd/display: Reject gpio_bitshift >= 32 in", " bios_parser_get_gpio_pin_info()", " - mm/damon/ops-common: call folio_test_lru() after folio_get()", " - ARM: socfpga: Fix OF node refcount leak in SMP setup", " - ARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O", " - mptcp: fix retransmission loop when csum is enabled", " - mptcp: sockopt: check timestamping ret value", " - selftests: mptcp: add test for extra_subflows underflow on userspace PM", " - ASoC: fsl_sai: Fix 32 slots TDM broken by integer shift UB in xMR write", " - inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush", " - pidfd: refuse access to tasks that have started exiting harder", " - i2c: stm32f7: fix timing computation ignoring i2c-analog-filter", " - i2c: tegra: Fix NOIRQ suspend/resume", " - Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK)", " - Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard", " - net/mlx5: Reorder completion before putting command entry in", " cmd_work_handler", " - net: mv643xx: fix OF node refcount", " - octeontx2-af: fix memory leak in rvu_setup_hw_resources()", " - mmc: core: Fix host controller programming for fixed driver type", " - mmc: litex_mmc: Set mandatory idle clocks before CMD0", " - mmc: renesas_sdhi: Add OF entry for RZ/G2H SoC", " - mmc: sdhci: add signal voltage switch in sdhci_resume_host", " - slimbus: qcom-ngd-ctrl: fix OF node refcount", " - drm/amdgpu: restart the CS if some parts of the VM are still invalidated", " - fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling", " - driver core: reject devices with unregistered buses", " - mm/hugetlb: avoid false positive lockdep assertion", " - soc: qcom: ice: Fix race between qcom_ice_probe() and of_qcom_ice_get()", " - ipmi:ssif: Remove unnecessary indention", " - ipmi:ssif: NULL thread on error", " - selftests: mptcp: drop nanoseconds width specifier", " - tty: serial: samsung: use u32 for register interactions", " - RDMA/umem: fix kernel-doc warnings", " - RDMA: Move DMA block iterator logic into dedicated files", " - arm64: cputype: Add NVIDIA Olympus definitions", " - arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU", " - mptcp: add-addr: always drop other suboptions", " - mptcp: fix missing wakeups in edge scenarios", " - Revert \"selftest/ptp: update ptp selftest to exercise the gettimex", " options\"", " - ARM: fix hash_name() fault", " - wifi: remove zero-length arrays", " - soc: qcom: ice: Return -ENODEV if the ICE platform device is not found", " - Bluetooth: ISO: Fix not using bc_sid as advertisement SID", " - octeontx2-pf: Fix NDC sync operation errors", " - octeontx2-af: Fix initialization of mcam's entry2target_pffunc field", " - ima: kexec: skip IMA segment validation after kexec soft reboot", " - ima: kexec: move IMA log copy from kexec load to execute", " - gpio: zynq: fix runtime PM leak on remove", " - writeback: Avoid contention on wb->list_lock when switching inodes", " - writeback: Fix use after free in inode_switch_wbs_work_fn()", " - xfrm: hold device only for the asynchronous decryption", " - KVM: VMX: Update SVI during runtime APICv activation", " - drm/xe: fix refcount leak in xe_range_fence_insert()", " - slimbus: qcom-ngd-ctrl: Fix up platform_driver registration", " - slimbus: qcom-ngd-ctrl: Fix probe error path ordering", " - slimbus: qcom-ngd-ctrl: Initialize controller resources in controller", " - slimbus: qcom-ngd-ctrl: Correct PDR and SSR cleanup ownership", " - slimbus: qcom-ngd-ctrl: Balance pm_runtime enablement for NGD", " - drm/amd/pm: fix smu13 power limit default/cap calculation", " - drm/amd/pm: smu_v14_0_0: use SoftMin for gfxclk in", " set_soft_freq_limited_range", " - drm/amd/display: add missing CSC entries for BT.2020 for DCE IPs", " - mailbox: Fix NULL message support in mbox_send_message()", " - vsock/virtio: fix skb overhead accounting to preserve full buf_alloc", " - net: introduce EXPORT_IPV6_MOD() and EXPORT_IPV6_MOD_GPL()", " - mptcp: pm: fix extra_subflows underflow on userspace PM subflow creation", " - vsock/virtio: fix skb overhead overflow on 32-bit builds", " - Upstream stable to v6.6.143, v6.12.94", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53132", " - vsock/virtio: fix potential unbounded skb queue", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53138", " - drm/amd/display: Bound VBIOS record-chain walk loops", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53140", " - drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53332", " - slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53156", " - nvmem: core: fix use-after-free bugs in error paths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53202", " - accel/ivpu: Fix signed integer truncation in IPC receive", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53205", " - accel/ivpu: Add bounds checks for firmware log indices", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53210", " - tee: shm: fix shm leak in register_shm_helper()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-31663", " - xfrm: hold dev ref until after transport_finish NF_HOOK", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53220", " - netfilter: revalidate bridge ports", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53229", " - net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-46203", " - spi: cadence-quadspi: fix unclocked access on unbind", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63871", " - Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53251", " - Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63869", " - wifi: mac80211: limit injected antenna index in", " ieee80211_parse_tx_radiotap", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53261", " - devlink: Release nested relation on devlink free", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53262", " - l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses", " - arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-45850", " - ipvs: skip ipv6 extension headers for csum checks", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53133", " - RDMA/umem: Fix truncation for block sizes >= 4G", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52908", " - RDMA: During rereg_mr ensure that REREG_ACCESS is compatible", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53199", " - hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53134", " - netfilter: nft_fib: fix stale stack leak via the OIFNAME register", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63883", " - serial: qcom_geni: fix kfifo underflow when flush precedes DMA", " completion IRQ", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-64528", " - tty: serial: samsung: Remove redundant port lock acquisition in rx", " helpers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53329", " - drm/amd/display: Use krealloc_array() in dal_vector_reserve()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53135", " - drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53136", " - drm/amd/display: Clamp VBIOS HDMI retimer register count to array size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53137", " - drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53143", " - drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on", " GFX11", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53144", " - drm/amdkfd: fix NULL dereference in get_queue_ids()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53331", " - slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53146", " - thunderbolt: Limit XDomain response copy to actual frame size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53147", " - thunderbolt: Validate XDomain request packet size before type cast", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53148", " - thunderbolt: Clamp XDomain response data copy to allocation size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53149", " - thunderbolt: Bound root directory content to block size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53150", " - thunderbolt: Reject zero-length property entries in validator", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52929", " - sctp: stream: fully roll back denied add-stream state", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52917", " - sctp: diag: reject stale associations in dump_one path", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53154", " - mm/hugetlb: restore reservation on error in hugetlb folio copy paths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53336", " - nvmem: layouts: onie-tlv: fix hang on unknown types", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53337", " - net: bonding: fix NULL pointer dereference in bond_do_ioctl()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53158", " - misc: fastrpc: Fix NULL pointer dereference in rpmsg callback", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53159", " - misc: fastrpc: fix DMA address corruption due to find_vma misuse", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53160", " - misc: fastrpc: fix use-after-free race in fastrpc_map_create", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53161", " - misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52930", " - ipc/shm: serialize orphan cleanup with shm_nattch updates", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53339", " - i2c: qcom-cci: Fix NULL pointer dereference in cci_remove()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53168", " - fuse: reject fuse_notify() pagecache ops on directories", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53177", " - bnxt_en: Fix NULL pointer dereference", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53181", " - vsock/vmci: fix sk_ack_backlog leak on failed handshake", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53182", " - wifi: nl80211: reject oversized EMA RNR lists", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53183", " - mptcp: allow subflow rcv wnd to shrink", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63867", " - mptcp: close TOCTOU race while computing rcv_wnd", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53343", " - ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53184", " - udp: clear skb->dev before running a sockmap verdict", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53185", " - zram: fix use-after-free in zram_bvec_write_partial()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53190", " - drm/virtio: fix dma_fence refcount leak on error in", " virtio_gpu_dma_fence_wait()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53194", " - USB: serial: kl5kusb105: fix bulk-out buffer overflow", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53195", " - USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53196", " - USB: serial: io_ti: fix heap overflow in get_manuf_info()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52935", " - xfrm: espintcp: do not reuse an in-progress partial send", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53198", " - ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53356", " - drm/i915/gem: Fix phys BO pread/pwrite with offset", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53345", " - KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53208", " - Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53209", " - Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53213", " - drm/vc4: fix krealloc() memory leak", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53347", " - drm/virtio: Fix driver removal with disabled KMS", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43116", " - netfilter: ctnetlink: ensure safe access to master conntrack", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53214", " - ipv6: Fix a potential NPD in cleanup_prefix_route()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53217", " - net: mvpp2: sync RX data at the hardware packet offset", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53218", " - netfilter: nft_exthdr: fix register tracking for F_PRESENT flag", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52942", " - netfilter: nf_log: validate MAC header was set before dumping it", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53219", " - netfilter: x_tables: avoid leaking percpu counter pointers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53349", " - netfilter: nf_conntrack: destroy stale expectfn expectations on", " unregister", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52939", " - net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic", " completion", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53223", " - net: guard timestamp cmsgs to real error queue skbs", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53227", " - net: openvswitch: fix possible kfree_skb of ERR_PTR", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53230", " - net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52947", " - net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53232", " - net: phy: clean the sfp upstream if phy probing fails", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53236", " - tcp: restrict SO_ATTACH_FILTER to priv users", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53350", " - ASoC: wm_adsp: Fix NULL dereference when removing firmware controls", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53237", " - gpio: mvebu: fix NULL pointer dereference in suspend/resume", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53238", " - netlabel: validate unlabeled address and mask attribute lengths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53239", " - xfrm: policy: fix use-after-free on inexact bin in", " xfrm_policy_bysel_ctx()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-46320", " - tap: free page on error paths in tap_get_user_xdp()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53242", " - ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked", " streams", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53352", " - signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53245", " - net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63870", " - ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53249", " - ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53252", " - Bluetooth: fix memory leak in error path of hci_alloc_dev()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53253", " - Bluetooth: bnep: reject short frames before parsing", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53254", " - Bluetooth: RFCOMM: validate skb length in MCC handlers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53255", " - Bluetooth: MGMT: validate advertising TLV before type checks", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53256", " - Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63868", " - net: garp: fix unsigned integer underflow in garp_pdu_parse_attr", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53353", " - hsr: Remove WARN_ONCE() in hsr_addr_is_self().", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53263", " - 6lowpan: fix off-by-one in multicast context address compression", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53264", " - net/sched: act_api: use RCU with deferred freeing for action lifecycle", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53265", " - dm cache policy smq: check allocation under invalidate lock", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53266", " - netfilter: bridge: make ebt_snat ARP rewrite writable", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53267", " - netfilter: nft_ct: bail out on template ct in get eval", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53268", " - netfilter: conntrack_irc: fix possible out-of-bounds read", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53269", " - netfilter: synproxy: add mutex to guard hook reference counting", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53270", " - ipvs: clear the svc scheduler ptr early on edit", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53273", " - tee: optee: prevent use-after-free when the client exits before the", " supplicant", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53274", " - net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53275", " - ipv6: mcast: Fix use-after-free when processing MLD queries", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52948", " - i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63898", " - USB: serial: mct_u232: fix memory corruption with small endpoint", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52910", " - bpf: Free reuseport cBPF prog after RCU grace period.", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43311", " - soc/tegra: pmc: Fix unsafe generic_handle_irq() call", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43240", " - x86/kexec: add a sanity check on previous kernel's ima kexec buffer", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-23346", " - arm64: io: Extract user memory type in ioremap_prot()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52944", " - ksmbd: fix FSCTL permission bypass by adding a permission check for", " FSCTL_SET_SPARSE", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-64006", " - netfilter: nf_tables: fix dst corruption in same register operation", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547)", " - Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size", " - drm/v3d: Fix use-after-free of CPU job query arrays on error path", " - drm/v3d: Release indirect CSD GEM reference on CPU job free", " - xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit", " - net/sched: sch_sfb: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - bcache: fix uninitialized closure object", " - nfc: llcp: Fix use-after-free in llcp_sock_release()", " - nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()", " - xfrm: Check for underflow in xfrm_state_mtu", " - nfc: nxp-nci: i2c: use rising-edge IRQ on ACPI systems", " - kunit: fix use-after-free in debugfs when using kunit.filter", " - netfilter: xt_cpu: prefer raw_smp_processor_id", " - vsock: keep poll shutdown state consistent", " - net: netlink: fix sending unassigned nsid after assigned one", " - net: netlink: don't set nsid on local notifications", " - net/smc: Do not re-initialize smc hashtables", " - net/iucv: fix locking in .getsockopt", " - scsi: core: Run queues for all non-SDEV_DEL devices from", " scsi_run_host_queues", " - ipv4: free net->ipv4.sysctl_local_reserved_ports after", " unregister_net_sysctl_table()", " - ALSA: pcm: oss: Fix setup list UAF on proc write error", " - ASoC: Intel: bytcht_es8316: Fix MCLK leak on init errors", " - gpio: mxc: fix irq_high handling", " - ethtool: rss: fix hkey leak when indir_size is 0", " - ASoC: codecs: simple-mux: Fix enum control bounds check", " - Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt()", " - bonding: refuse to enslave CAN devices", " - ethtool: eeprom: add missing ethnl_ops_begin() / _complete() during", " fallback", " - ethtool: eeprom: add more safeties to EEPROM Netlink fallback", " - net/sched: Revert \"net/sched: Restrict conditions for adding duplicating", " netems to qdisc tree\"", " - net/handshake: Use spin_lock_bh for hn_lock", " - nvme-tcp: store negative errno in queue->tls_err", " - net/handshake: Pass negative errno through handshake_complete()", " - Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success", " - Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp", " - Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close", " - gpio: rockchip: convert bank->clk to devm_clk_get_enabled()", " - net: mana: Add NULL guards in teardown path to prevent panic on attach", " failure", " - sctp: fix race between sctp_wait_for_connect and peeloff", " - ipv6: fix possible infinite loop in rt6_fill_node()", " - ipv6: fix possible infinite loop in fib6_select_path()", " - net: skbuff: fix pskb_carve leaking zcopy pages", " - perf: Fix dangling cgroup pointer in cpuctx", " - batman-adv: tvlv: abort OGM send on tvlv append failure", " - batman-adv: tt: reject oversized local TVLV buffers", " - batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface", " - batman-adv: iv: recover OGM scheduling after forward packet error", " - batman-adv: tp_meter: avoid role confusion in tp_list", " - batman-adv: tp_meter: directly shut down timer on cleanup", " - batman-adv: tt: avoid empty VLAN responses", " - batman-adv: bla: avoid double decrement of bla.num_requests", " - media: rc: fix race between unregister and urb/irq callbacks", " - media: rc: ttusbir: fix inverted error logic", " - inet: frags: add inet_frag_queue_flush()", " - HID: core: Add printk_ratelimited variants to hid_warn() etc", " - drm/i915/psr: Add defininitions for INTEL_WA_REGISTER_CAPS DPCD register", " - drm/i915/psr: Read Intel DPCD workaround register", " - drm/dp: Add eDP 1.5 bit definition", " - drm/i915/psr: Apply Intel DPCD workaround when SDP on prior line used", " - phy: mscc: Use PHY_ID_MATCH_EXACT for VSC8584, VSC8582, VSC8575, VSC856X", " - batman-adv: tt: prevent TVLV entry number overflow", " - iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer", " - usb: typec: ucsi: ccg: reject firmware images without a ':' record", " header", " - usb: typec: ucsi: displayport: NAK DP_CMD_CONFIGURE without a payload", " VDO", " - usb: typec: altmodes/displayport: validate count before reading Status", " Update VDO", " - usb: typec: wcove: don't write past struct pd_message in", " wcove_read_rx_buffer()", " - usb: typec: tcpm/tcpci_maxim: validate header NDO against RX_BYTE_CNT", " - usb: typec: ucsi: validate connector number in ucsi_connector_change()", " - USB: serial: safe_serial: fix memory corruption with small endpoint", " - media: rc: igorplugusb: fix control request setup packet", " - Input: ims-pcu - fix usb_free_coherent() size in ims_pcu_buffers_free()", " - HID: quirks: Add ALWAYS_POLL quirk for SIGMACHIP USB mouse", " - Bluetooth: btusb: Allow firmware re-download when version matches", " - hpfs: fix a crash if hpfs_map_dnode_bitmap fails", " - auxdisplay: line-display: fix OOB read on zero-length message_store()", " - Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn", " - Bluetooth: HIDP: fix missing length checks in hidp_input_report()", " - Bluetooth: ISO: fix UAF in iso_recv_frame", " - Bluetooth: ISO: serialize iso_sock_clear_timer with socket lock", " - Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync", " - Input: xpad - fix out-of-bounds access for Share button", " - parport: Fix race between port and client registration", " - USB: cdc-acm: Fix bit overlap and move quirk definitions to header", " - KVM: arm64: PMU: Preserve AArch32 counter low bits", " - KVM: SVM: Flush the current TLB when transitioning from xAVIC => x2AVIC", " - iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux", " - iio: adc: npcm: fix unbalanced clk_disable_unprepare()", " - iio: dac: max5821: fix return value check in powerdown sync", " - iio: dac: ad5686: fix input raw value check", " - iio: dac: ad5686: acquire lock when doing powerdown control", " - iio: adc: viperboard: Fix error handling in vprbrd_iio_read_raw", " - iio: gyro: itg3200: fix i2c read into the wrong stack location", " - iio: gyro: adis16260: fix division by zero in write_raw", " - iio: ssp_sensors: cancel delayed work_refresh on remove", " - iio: temperature: tsys01: fix broken PROM checksum validation", " - iio: magnetometer: st_magn: fix default DRDY pin selection for LIS2MDL", " - iio: light: cm3323: fix reg_conf not being initialized correctly", " - iio: buffer: hw-consumer: fix use-after-free in error path", " - USB: serial: omninet: fix memory corruption with small endpoint", " - usb: cdns3: gadget: fix request skipping after clearing halt", " - usb: cdns3: plat: fix leaked usb2_phy initialization on usb3_phy", " acquisition failure", " - usb: cdns3: plat: fix unbalanced pm_runtime_forbid() call permanently", " leaks the runtime PM usage counter across bind/unbind cycles", " - usb: dwc2: Fix use after free in debug code", " - Input: elan_i2c - validate firmware size before use", " - wireguard: send: append trailer after expanding head", " - bpf: sockmap: fix tail fragment offset in bpf_msg_push_data", " - macsec: fix replay protection at XPN lower-PN wrap", " - ASoC: qcom: q6asm-dai: fix error handling in prepare and set_params", " - ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().", " - ipv6: validate extension header length before copying to cmsg", " - xfrm: input: hold netns during deferred transport reinjection", " - ip6: vti: Use ip6_tnl.net in vti6_changelink().", " - HID: wacom: Fix OOB write in wacom_hid_set_device_mode()", " - iommu, debugobjects: avoid gcc-16.1 section mismatch warnings", " - nfc: hci: fix out-of-bounds read in HCP header parsing", " - xfrm: route MIGRATE notifications to caller's netns", " - xfrm: ah: use skb_to_full_sk in async output callbacks", " - ALSA: scarlett2: Fix 2i2 Gen 4 direct monitor gain on firmware 2417", " - netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without", " direction check", " - ASoC: qcom: q6asm-dai: close stream only when running", " - ASoC: qcom: q6asm-dai: do not set stream state in event and trigger", " callbacks", " - Input: xpad - add \"Nova 2 Lite\" from GameSir", " - Input: xpad - add support for ASUS ROG RAIKIRI II", " - ksmbd: OOB read regression in smb_check_perm_dacl() ACE-walk loops", " - Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem", " - Input: synaptics - add LEN2058 to SMBus passlist for ThinkPad E490", " - comedi: comedi_test: fix check for valid scan_begin_src in", " waveform_ai_cmdtest()", " - comedi: comedi_test: Fix limiting of convert_arg in", " waveform_ai_cmdtest()", " - counter: Fix refcount leak in counter_alloc() error path", " - tty: serial: pch_uart: add check for dma_alloc_coherent()", " - usb: chipidea: core: convert ci_role_switch to local variable", " - usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval", " - USB: quirks: add NO_LPM for Lenovo ThinkPad USB-C Dock Gen2 hub", " controllers", " - usb: storage: Add quirks for PNY Elite Portable SSD", " - usbip: vudc: Fix use after free bug in vudc_remove due to race condition", " - usb: usbtmc: check URB actual_length for interrupt-IN notifications", " - usb: usbtmc: reject interrupt endpoints with small wMaxPacketSize", " - USB: serial: option: add MeiG SRM813Q", " - USB: serial: option: add missing RSVD(5) flag for Rolling RW135R-GL", " - USB: serial: belkin_sa: validate interrupt status length", " - USB: serial: cypress_m8: validate interrupt packet headers", " - USB: serial: keyspan: fix missing indat transfer sanity check", " - USB: serial: mxuport: fix memory corruption with small endpoint", " - USB: serial: mct_u232: fix missing interrupt-in transfer sanity check", " - usb: gadget: uvc: hold opts->lock across XU walks in uvc_function_bind", " - usb: gadget: net2280: Fix double free in probe error path", " - usb: gadget: f_hid: fix device reference leak in hidg_alloc()", " - usb: gadget: composite: fix integer underflow in WebUSB GET_URL handling", " - usb: gadget: dummy_hcd: Reject hub port requests for non-existent ports", " - usb: gadget: f_fs: copy only received bytes on short ep0 read", " - thunderbolt: property: Reject u32 wrap in tb_property_entry_valid()", " - thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow", " - scsi: fcoe: Reject FIP descriptors with zero fip_dlen in CVL walker", " - scsi: scsi_transport_fc: Widen FPIN pname walker counter to u32", " - drm/hyperv: validate resolution_count and fix WIN8 fallback", " - drm/hyperv: validate VMBus packet size in receive callback", " - drm/i915: Fix potential UAF in TTM object purge", " - drm/amd/pm/si: Disregard vblank time when no displays are connected", " - serial: altera_jtaguart: handle uart_add_one_port() failures", " - serial: qcom-geni: fix UART_RX_PAR_EN bit position", " - serial: sh-sci: fix memory region release in error path", " - serial: zs: Fix swapped RI/DSR modem line transition counting", " - serial: fsl_lpuart: fix rx buffer and DMA map leaks in start_rx_dma", " - drm/amdkfd: fix NULL pointer bug in svm_range_set_attr", " - drm/amdkfd: fix a vulnerability of integer overflow in kfd debugger", " - drm/amdkfd: Check for pdd drm file first in CRIU restore path", " - serial: dz: Fix bootconsole message clobbering at chip reset", " - serial: dz: Fix bootconsole handover lockup", " - serial: dz: Convert to use a platform device", " - serial: zs: Fix bootconsole handover lockup", " - serial: zs: Switch to using channel reset", " - serial: zs: Convert to use a platform device", " - USB: serial: cypress_m8: fix memory corruption with small endpoint", " - USB: serial: digi_acceleport: fix memory corruption with small endpoints", " - xhci: tegra: Fix ghost USB device on dual-role port unplug", " - iommu: Skip PASID validation for devices without PASID capability", " - x86/boot: Disable stack protector for early boot code", " - rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg", " - rxrpc: Fix RESPONSE packet verification to extract skb to a linear", " buffer", " - serdev: Provide a bustype shutdown function", " - Bluetooth: hci_qca: Migrate to serdev specific shutdown function", " - Bluetooth: hci_qca: Convert timeout from jiffies to ms", " - ALSA: scarlett2: Return ENOSPC for out-of-bounds flash writes", " - ALSA: scarlett2: Allow flash writes ending at segment boundary", " - mm/memory: fix spurious warning when unmapping device-private/exclusive", " pages", " - platform/x86/intel/vsec: Fix enable_cnt imbalance on PCIe error recovery", " - net: hsr: defer node table free until after RCU readers", " - mptcp: pm: fix ADD_ADDR timer infinite retry on option space", " insufficient", " - ice: fix VF queue configuration with low MTU values", " - mptcp: cleanup fallback dummy mapping generation", " - mptcp: reset rcv wnd on disconnect", " - arm64: tlb: Flush walk cache when unsharing PMD tables", " - octeontx2-pf: avoid double free of pool->stack on AQ init failure", " - mptcp: introduce the mptcp_init_skb helper", " - mptcp: handle first subflow closing consistently", " - mptcp: do not drop partial packets", " - mm/damon/sysfs-schemes: delete tried region in regions_rmdirs()", " - iio: chemical: scd30: Use guard(mutex) to allow early returns", " - iio: chemical: scd30: fix division by zero in write_raw", " - iio: dac: ad5686: fix ref bit initialization for single-channel parts", " - ALSA: firewire-motu: Protect register DSP event queue positions", " - usb: dwc3: xilinx: fix error handling in zynqmp init error paths", " - usb: musb: omap2430: Fix use-after-free in omap2430_probe()", " - usb: typec: ucsi: Check if power role change actually happened before", " handling", " - thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()", " - usb: typec: ucsi: Don't update power_supply on power role change if not", " connected", " - hwmon: (pmbus/adm1266) serialize sequencer_state debugfs read with", " pmbus_lock", " - hwmon: (pmbus/adm1266) serialize NVMEM blackbox read with pmbus_lock", " - hwmon: (pmbus/adm1266) serialize GPIO PMBus accesses with pmbus_lock", " - mm: perform all memfd seal checks in a single place", " - mm/memfd: fix spelling and grammatical issues", " - memfd: deny writeable mappings when implying SEAL_WRITE", " - usb: core: Fix SuperSpeed root hub wMaxPacketSize", " - Upstream stable to v6.12.93", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43331", " - x86/kexec: Disable KCOV instrumentation after load_segments()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52943", " - net: skbuff: fix missing zerocopy reference in pskb_carve helpers", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-53358", " - Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52923", " - ipc: limit next_id allocation to the valid ID range", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2025-68768", " - inet: frags: flush pending skbs in fqdir_pre_exit()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43303", " - mm/page_alloc: clear page->private in free_pages_prepare()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52934", " - batman-adv: tvlv: reject oversized TVLV packets", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52913", " - batman-adv: v: stop OGMv2 on disabled interface", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-46322", " - tun: free page on build_skb failure in tun_xdp_one()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-46321", " - tun: free page on short-frame rejection in tun_xdp_one()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52927", " - netfilter: ebtables: fix OOB read in compat_mtw_from_user", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43219", " - net: cpsw_new: Fix potential unregister of netdev that has not been", " registered yet", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-45930", " - net: mctp: ensure our nlmsg responses are initialised", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-53080", " - net/sched: cls_fw: fix NULL dereference of \"old\" filters before change()", "", " * 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-146.146", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2166353, 1786013, 2165873, 2164507, 2163508, 2161004, 2089306, 2164716, 2164516, 2132119, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547 ], "author": "Edoardo Canepa ", "date": "Thu, 03 Sep 2026 17:47:58 +0300" } ], "notes": "linux-modules-6.8.0-146-generic version '6.8.0-146.146' (source package linux version '6.8.0-146.146') was added. linux-modules-6.8.0-146-generic version '6.8.0-146.146' has the same source package name, linux, as removed package linux-modules-6.8.0-139-generic. As such we can use the source package version of the removed package, '6.8.0-139.139', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-image-6.8.0-139-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-139.139", "version": "6.8.0-139.139" }, "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-6.8.0-139-generic", "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": 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 20260905 to 20261001", "from_series": "noble", "to_series": "noble", "from_serial": "20260905", "to_serial": "20261001", "from_manifest_filename": "release_manifest.previous", "to_manifest_filename": "manifest.current" }