{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-headers-5.15.0-1108-kvm", "linux-image-5.15.0-1108-kvm", "linux-kvm-headers-5.15.0-1108", "linux-modules-5.15.0-1108-kvm" ], "removed": [ "linux-headers-5.15.0-1107-kvm", "linux-image-5.15.0-1107-kvm", "linux-kvm-headers-5.15.0-1107", "linux-modules-5.15.0-1107-kvm" ], "diff": [ "libexpat1", "libglib2.0-0", "libglib2.0-data", "linux-headers-kvm", "linux-image-kvm", "linux-kvm" ] } }, "diff": { "deb": [ { "name": "libexpat1", "from_version": { "source_package_name": "expat", "source_package_version": "2.4.7-1ubuntu0.7", "version": "2.4.7-1ubuntu0.7" }, "to_version": { "source_package_name": "expat", "source_package_version": "2.4.7-1ubuntu0.8", "version": "2.4.7-1ubuntu0.8" }, "cves": [ { "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-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-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-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: 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/runtests.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/runtests.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/runtests.c.", " - CVE-2026-32778", " * 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, expat/lib/expat.h.", " - 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/runtests.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.4.7-1ubuntu0.8", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Isabel Garcia Contreras ", "date": "Tue, 15 Sep 2026 14:39:46 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libglib2.0-0", "from_version": { "source_package_name": "glib2.0", "source_package_version": "2.72.4-0ubuntu2.9", "version": "2.72.4-0ubuntu2.9" }, "to_version": { "source_package_name": "glib2.0", "source_package_version": "2.72.4-0ubuntu2.10", "version": "2.72.4-0ubuntu2.10" }, "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.72.4-0ubuntu2.10", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Leonidas Da Silva Barbosa ", "date": "Tue, 08 Sep 2026 14:07:49 -0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "libglib2.0-data", "from_version": { "source_package_name": "glib2.0", "source_package_version": "2.72.4-0ubuntu2.9", "version": "2.72.4-0ubuntu2.9" }, "to_version": { "source_package_name": "glib2.0", "source_package_version": "2.72.4-0ubuntu2.10", "version": "2.72.4-0ubuntu2.10" }, "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.72.4-0ubuntu2.10", "urgency": "medium", "distributions": "jammy-security", "launchpad_bugs_fixed": [], "author": "Leonidas Da Silva Barbosa ", "date": "Tue, 08 Sep 2026 14:07:49 -0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-headers-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1107.103", "version": "5.15.0.1107.103" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1108.104", "version": "5.15.0.1108.104" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1108", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1108.104", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Thibault Ferrante ", "date": "Mon, 07 Sep 2026 17:13:42 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1107.103", "version": "5.15.0.1107.103" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1108.104", "version": "5.15.0.1108.104" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1108", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1108.104", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Thibault Ferrante ", "date": "Mon, 07 Sep 2026 17:13:42 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1107.103", "version": "5.15.0.1107.103" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1108.104", "version": "5.15.0.1108.104" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1108", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1108.104", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Thibault Ferrante ", "date": "Mon, 07 Sep 2026 17:13:42 +0200" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-headers-5.15.0-1108-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1107.112", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1108.113", "version": "5.15.0-1108.113" }, "cves": [ { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12: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-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-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-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-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-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-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" } ], "launchpad_bugs_fixed": [ 2165645, 1786013, 2165998, 1786013, 2165659, 2164800 ], "changes": [ { "cves": [ { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12: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-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-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-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-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-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-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" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1108.113 -proposed tracker (LP: #2165645)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.kvm/dkms-versions -- update from kernel-versions", " (main/s2026.08.03)", "", " [ Ubuntu: 5.15.0-194.204 ]", "", " * jammy/linux: 5.15.0-194.204 -proposed tracker (LP: #2165998)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/s2026.08.03)", "", " [ Ubuntu: 5.15.0-192.202 ]", "", " * jammy/linux: 5.15.0-192.202 -proposed tracker (LP: #2165659)", " * CVE-2026-53398", " - NFSD: Fix SECINFO_NO_NAME decode error cleanup", " * CVE-2026-63800", " - pNFS: Fix use-after-free in pnfs_update_layout()", " * CVE-2026-63808", " - exfat: fix potential use-after-free in exfat_find_dir_entry()", " * CVE-2025-10263 // CVE-2026-53354", " - arm64: errata: Mitigate TLBI errata on various Arm CPUs", " - [Config] Set CONFIG_ARM64_ERRATUM_4118414=y", " * CVE-2025-10263", " - arm64: cputype: Add C1-Premium definitions", " - arm64: cputype: Add C1-Ultra definitions", " * CVE-2026-63888", " - scsi: target: iscsi: Fix CRC overread and double-free in", " iscsit_handle_text_cmd()", " * CVE-2026-63887", " - scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf", " * 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-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-64007", " - netfilter: synproxy: refresh tcphdr after skb_ensure_writable", " * CVE-2026-53221", " - ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()", " * SAUCE: Revert erroneous application of \"netfilter: nf_tables: fix inverted", " genmask check in nft_map_catchall_activate()\" (LP: #2164800)", " - SAUCE: Revert \"netfilter: nf_tables: fix inverted genmask check in", " nft_map_catchall_activate()\"", "" ], "package": "linux-kvm", "version": "5.15.0-1108.113", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2165645, 1786013, 2165998, 1786013, 2165659, 2164800 ], "author": "Thibault Ferrante ", "date": "Mon, 07 Sep 2026 17:13:09 +0200" } ], "notes": "linux-headers-5.15.0-1108-kvm version '5.15.0-1108.113' (source package linux-kvm version '5.15.0-1108.113') was added. linux-headers-5.15.0-1108-kvm version '5.15.0-1108.113' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1107-kvm. As such we can use the source package version of the removed package, '5.15.0-1107.112', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-image-5.15.0-1108-kvm", "from_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1107.112", "version": null }, "to_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1108.113", "version": "5.15.0-1108.113" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 5.15.0-1108.113", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed-kvm", "version": "5.15.0-1108.113", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Thibault Ferrante ", "date": "Mon, 07 Sep 2026 17:13:59 +0200" } ], "notes": "linux-image-5.15.0-1108-kvm version '5.15.0-1108.113' (source package linux-signed-kvm version '5.15.0-1108.113') was added. linux-image-5.15.0-1108-kvm version '5.15.0-1108.113' has the same source package name, linux-signed-kvm, as removed package linux-image-5.15.0-1107-kvm. As such we can use the source package version of the removed package, '5.15.0-1107.112', 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-kvm-headers-5.15.0-1108", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1107.112", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1108.113", "version": "5.15.0-1108.113" }, "cves": [ { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12: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-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-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-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-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-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-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" } ], "launchpad_bugs_fixed": [ 2165645, 1786013, 2165998, 1786013, 2165659, 2164800 ], "changes": [ { "cves": [ { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12: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-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-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-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-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-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-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" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1108.113 -proposed tracker (LP: #2165645)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.kvm/dkms-versions -- update from kernel-versions", " (main/s2026.08.03)", "", " [ Ubuntu: 5.15.0-194.204 ]", "", " * jammy/linux: 5.15.0-194.204 -proposed tracker (LP: #2165998)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/s2026.08.03)", "", " [ Ubuntu: 5.15.0-192.202 ]", "", " * jammy/linux: 5.15.0-192.202 -proposed tracker (LP: #2165659)", " * CVE-2026-53398", " - NFSD: Fix SECINFO_NO_NAME decode error cleanup", " * CVE-2026-63800", " - pNFS: Fix use-after-free in pnfs_update_layout()", " * CVE-2026-63808", " - exfat: fix potential use-after-free in exfat_find_dir_entry()", " * CVE-2025-10263 // CVE-2026-53354", " - arm64: errata: Mitigate TLBI errata on various Arm CPUs", " - [Config] Set CONFIG_ARM64_ERRATUM_4118414=y", " * CVE-2025-10263", " - arm64: cputype: Add C1-Premium definitions", " - arm64: cputype: Add C1-Ultra definitions", " * CVE-2026-63888", " - scsi: target: iscsi: Fix CRC overread and double-free in", " iscsit_handle_text_cmd()", " * CVE-2026-63887", " - scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf", " * 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-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-64007", " - netfilter: synproxy: refresh tcphdr after skb_ensure_writable", " * CVE-2026-53221", " - ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()", " * SAUCE: Revert erroneous application of \"netfilter: nf_tables: fix inverted", " genmask check in nft_map_catchall_activate()\" (LP: #2164800)", " - SAUCE: Revert \"netfilter: nf_tables: fix inverted genmask check in", " nft_map_catchall_activate()\"", "" ], "package": "linux-kvm", "version": "5.15.0-1108.113", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2165645, 1786013, 2165998, 1786013, 2165659, 2164800 ], "author": "Thibault Ferrante ", "date": "Mon, 07 Sep 2026 17:13:09 +0200" } ], "notes": "linux-kvm-headers-5.15.0-1108 version '5.15.0-1108.113' (source package linux-kvm version '5.15.0-1108.113') was added. linux-kvm-headers-5.15.0-1108 version '5.15.0-1108.113' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1107-kvm. As such we can use the source package version of the removed package, '5.15.0-1107.112', 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-5.15.0-1108-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1107.112", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1108.113", "version": "5.15.0-1108.113" }, "cves": [ { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12: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-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-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-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-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-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-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" } ], "launchpad_bugs_fixed": [ 2165645, 1786013, 2165998, 1786013, 2165659, 2164800 ], "changes": [ { "cves": [ { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12: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-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-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-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-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-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-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" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1108.113 -proposed tracker (LP: #2165645)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.kvm/dkms-versions -- update from kernel-versions", " (main/s2026.08.03)", "", " [ Ubuntu: 5.15.0-194.204 ]", "", " * jammy/linux: 5.15.0-194.204 -proposed tracker (LP: #2165998)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/s2026.08.03)", "", " [ Ubuntu: 5.15.0-192.202 ]", "", " * jammy/linux: 5.15.0-192.202 -proposed tracker (LP: #2165659)", " * CVE-2026-53398", " - NFSD: Fix SECINFO_NO_NAME decode error cleanup", " * CVE-2026-63800", " - pNFS: Fix use-after-free in pnfs_update_layout()", " * CVE-2026-63808", " - exfat: fix potential use-after-free in exfat_find_dir_entry()", " * CVE-2025-10263 // CVE-2026-53354", " - arm64: errata: Mitigate TLBI errata on various Arm CPUs", " - [Config] Set CONFIG_ARM64_ERRATUM_4118414=y", " * CVE-2025-10263", " - arm64: cputype: Add C1-Premium definitions", " - arm64: cputype: Add C1-Ultra definitions", " * CVE-2026-63888", " - scsi: target: iscsi: Fix CRC overread and double-free in", " iscsit_handle_text_cmd()", " * CVE-2026-63887", " - scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf", " * 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-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-64007", " - netfilter: synproxy: refresh tcphdr after skb_ensure_writable", " * CVE-2026-53221", " - ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()", " * SAUCE: Revert erroneous application of \"netfilter: nf_tables: fix inverted", " genmask check in nft_map_catchall_activate()\" (LP: #2164800)", " - SAUCE: Revert \"netfilter: nf_tables: fix inverted genmask check in", " nft_map_catchall_activate()\"", "" ], "package": "linux-kvm", "version": "5.15.0-1108.113", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2165645, 1786013, 2165998, 1786013, 2165659, 2164800 ], "author": "Thibault Ferrante ", "date": "Mon, 07 Sep 2026 17:13:09 +0200" } ], "notes": "linux-modules-5.15.0-1108-kvm version '5.15.0-1108.113' (source package linux-kvm version '5.15.0-1108.113') was added. linux-modules-5.15.0-1108-kvm version '5.15.0-1108.113' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1107-kvm. As such we can use the source package version of the removed package, '5.15.0-1107.112', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-headers-5.15.0-1107-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1107.112", "version": "5.15.0-1107.112" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-5.15.0-1107-kvm", "from_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1107.112", "version": "5.15.0-1107.112" }, "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-kvm-headers-5.15.0-1107", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1107.112", "version": "5.15.0-1107.112" }, "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-5.15.0-1107-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1107.112", "version": "5.15.0-1107.112" }, "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 22.04 jammy image from release image serial 20260917 to 20260922", "from_series": "jammy", "to_series": "jammy", "from_serial": "20260917", "to_serial": "20260922", "from_manifest_filename": "release_manifest.previous", "to_manifest_filename": "manifest.current" }